Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.4.5, 3.5.0
    • Fix Version/s: 3.4.7, 3.5.0
    • Component/s: None
    • Labels:
      None

      Description

      There are two problems I have spotted when running "make check" with the C client. First, it complains that the sleep call is not defined in two test files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. Including unistd.h works. The second problem is with linker options. It complains that "--wrap" is not a valid. I'm not sure how to deal with this one yet, since I'm not sure why we are using it.

      1. ZOOKEEPER-1742-3.4.patch
        47 kB
        Germán Blanco
      2. ZOOKEEPER-1742-3.4.patch
        46 kB
        Germán Blanco
      3. ZOOKEEPER-1742.patch
        46 kB
        Germán Blanco
      4. ZOOKEEPER-1742.patch
        46 kB
        Germán Blanco
      5. ZOOKEEPER-1742-3.4.patch
        43 kB
        Germán Blanco
      6. ZOOKEEPER-1742.patch
        46 kB
        Germán Blanco
      7. ZOOKEEPER-1742-3.4.patch
        43 kB
        Germán Blanco
      8. ZOOKEEPER-1742-3.4.patch
        41 kB
        Germán Blanco
      9. ZOOKEEPER-1742.patch
        44 kB
        Germán Blanco
      10. ZOOKEEPER-1742-3.4.patch
        42 kB
        Germán Blanco
      11. ZOOKEEPER-1742.patch
        44 kB
        Germán Blanco

        Issue Links

          Activity

          Hide
          Michi Mutsuzaki added a comment -

          It sounds like the patch is ready for review yet. Canceling.

          Show
          Michi Mutsuzaki added a comment - It sounds like the patch is ready for review yet. Canceling.
          Hide
          Flavio Junqueira added a comment -

          What I'm hearing is that no one is confident that we have the right solution quite yet, so I propose we bump it to 3.4.7, 3.5.0.

          Show
          Flavio Junqueira added a comment - What I'm hearing is that no one is confident that we have the right solution quite yet, so I propose we bump it to 3.4.7, 3.5.0.
          Hide
          Germán Blanco added a comment -

          Silly me, the failure in testAuth doesn't have to do with SASL.
          Only for the sake of completeness, here is the patch that runs successfully in branch 3.4 on my macos (it runs 28 single threaded tests and 55 multithreaded tests). However, some of these failures could be caused by e.g. underlying race conditions and timing issues, so there could be more failures for others.

          QA fails because this is a patch for 3.4.

          It seems to me that the test failures on macos should be handled in a separate JIRA, since they don't seem related with the -wrap option compiler failure. In this JIRA then, there will be a pending decision on whether to change the wrapping method (from the ld -wrap option to the macros) so that tests compile on macos.

          Show
          Germán Blanco added a comment - Silly me, the failure in testAuth doesn't have to do with SASL. Only for the sake of completeness, here is the patch that runs successfully in branch 3.4 on my macos (it runs 28 single threaded tests and 55 multithreaded tests). However, some of these failures could be caused by e.g. underlying race conditions and timing issues, so there could be more failures for others. QA fails because this is a patch for 3.4. It seems to me that the test failures on macos should be handled in a separate JIRA, since they don't seem related with the -wrap option compiler failure. In this JIRA then, there will be a pending decision on whether to change the wrapping method (from the ld -wrap option to the macros) so that tests compile on macos.
          Hide
          Benjamin Reed added a comment -

          here is the message that failed to post last night: i took a look at simply disabling the tests that don't work. for zktest-st i could get all but a dozen tests to pass, but there are so many tests that fail on zktest-mt that it becomes worthless. i suggest that we ignore this issue for the next release.

          in short. i concur with german.

          Show
          Benjamin Reed added a comment - here is the message that failed to post last night: i took a look at simply disabling the tests that don't work. for zktest-st i could get all but a dozen tests to pass, but there are so many tests that fail on zktest-mt that it becomes worthless. i suggest that we ignore this issue for the next release. in short. i concur with german.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12615451/ZOOKEEPER-1742-3.4.patch
          against trunk revision 1543281.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 35 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1802//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12615451/ZOOKEEPER-1742-3.4.patch against trunk revision 1543281. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 35 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1802//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          There are some test cases that fail in 3.4.
          This patch disables the 4 test cases that fail in 3.4 for macos so that the tests hopefully run succesfully.
          I haven't been able to test testAuth yet, because there is no SASL configured in my machine, but I think it should work. Note that if testAuth fails, then many other test cases fail after it for no additional reason.
          I personally think that the best option would be to make the release with this cases failing for macos and figure out what happens in 3.4.6. That sounds better than delaying the release because of this or disabling test cases that fail. But in case you prefer the "disabling" option, please try this.

          Show
          Germán Blanco added a comment - There are some test cases that fail in 3.4. This patch disables the 4 test cases that fail in 3.4 for macos so that the tests hopefully run succesfully. I haven't been able to test testAuth yet, because there is no SASL configured in my machine, but I think it should work. Note that if testAuth fails, then many other test cases fail after it for no additional reason. I personally think that the best option would be to make the release with this cases failing for macos and figure out what happens in 3.4.6. That sounds better than delaying the release because of this or disabling test cases that fail. But in case you prefer the "disabling" option, please try this.
          Hide
          Benjamin Reed added a comment -

          it doesn't work on 3.4 either

          Show
          Benjamin Reed added a comment - it doesn't work on 3.4 either
          Hide
          Flavio Junqueira added a comment -

          Benjamin Reed, I'd like to get this into 3.4.6. Have you tested with trunk only? If the patch is good for 3.4.6, we can have checked in to branch 3.4.

          Show
          Flavio Junqueira added a comment - Benjamin Reed , I'd like to get this into 3.4.6. Have you tested with trunk only? If the patch is good for 3.4.6, we can have checked in to branch 3.4.
          Hide
          Germán Blanco added a comment -

          OK, I can confirm that it would take me around a month to figure this out .

          Show
          Germán Blanco added a comment - OK, I can confirm that it would take me around a month to figure this out .
          Hide
          Germán Blanco added a comment -

          I see now there is a Mock_gettimeofday class.
          I haven't noticed before because this function is not wrapped, so it shouldn't be affected by my changes.
          But maybe there is something wrong in mac with it.
          i will try to take a look.

          Show
          Germán Blanco added a comment - I see now there is a Mock_gettimeofday class. I haven't noticed before because this function is not wrapped, so it shouldn't be affected by my changes. But maybe there is something wrong in mac with it. i will try to take a look.
          Hide
          Germán Blanco added a comment -

          Hello Benjamin Reed, thank you very much for testing!
          It also fails for me on mac, even though it works in Ubuntu, but it is very difficult for me to find the origin of the problem.
          Could you please give me a few more details on this "time mocking" problem?
          Which function or module is it where there is time mocking involved?

          Show
          Germán Blanco added a comment - Hello Benjamin Reed , thank you very much for testing! It also fails for me on mac, even though it works in Ubuntu, but it is very difficult for me to find the origin of the problem. Could you please give me a few more details on this "time mocking" problem? Which function or module is it where there is time mocking involved?
          Hide
          Benjamin Reed added a comment -

          this still fails for me on my mac. i think the time mocking doesn't seem to be working properly.

          Show
          Benjamin Reed added a comment - this still fails for me on my mac. i think the time mocking doesn't seem to be working properly.
          Hide
          Germán Blanco added a comment -

          Same failure, I guess I will have to wait until ZOOKEEPER-1805 is solved.

          Show
          Germán Blanco added a comment - Same failure, I guess I will have to wait until ZOOKEEPER-1805 is solved.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12614460/ZOOKEEPER-1742.patch
          against trunk revision 1542355.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 27 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12614460/ZOOKEEPER-1742.patch against trunk revision 1542355. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 27 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1788//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          Last failure was due to ZOOKEEPER-1805.
          I removed trailing spaces, just as an excuse to run the tests again.

          Show
          Germán Blanco added a comment - Last failure was due to ZOOKEEPER-1805 . I removed trailing spaces, just as an excuse to run the tests again.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12614453/ZOOKEEPER-1742.patch
          against trunk revision 1542355.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 27 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12614453/ZOOKEEPER-1742.patch against trunk revision 1542355. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 27 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1787//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          I mean AM_PROG_AR.
          Would it make sense to update the tools?

          Show
          Germán Blanco added a comment - I mean AM_PROG_AR. Would it make sense to update the tools?
          Hide
          Germán Blanco added a comment -

          same issue in the trunk patch.

          Show
          Germán Blanco added a comment - same issue in the trunk patch.
          Hide
          Germán Blanco added a comment -

          It seems that the autoconf in the machine where Jenkins is running does not support AC_PROG_AR macro.

          Show
          Germán Blanco added a comment - It seems that the autoconf in the machine where Jenkins is running does not support AC_PROG_AR macro.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12614431/ZOOKEEPER-1742.patch
          against trunk revision 1542355.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 27 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12614431/ZOOKEEPER-1742.patch against trunk revision 1542355. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 27 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1785//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          Removing warnings also in the trunk patch.

          Show
          Germán Blanco added a comment - Removing warnings also in the trunk patch.
          Hide
          Germán Blanco added a comment -

          Sorry, I forgot to do "svn add" to add the new file before generating the last patch.

          Show
          Germán Blanco added a comment - Sorry, I forgot to do "svn add" to add the new file before generating the last patch.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12614388/ZOOKEEPER-1742-3.4.patch
          against trunk revision 1542355.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 29 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1782//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12614388/ZOOKEEPER-1742-3.4.patch against trunk revision 1542355. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 29 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1782//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          The last 3.4 patch fixes the warnings for me. Please try it out.

          I think that some of these changes are not specific for macos and they might eventually be required in other platforms, so it might make sense to move the changes to another JIRA if this one doesn't make it.

          Show
          Germán Blanco added a comment - The last 3.4 patch fixes the warnings for me. Please try it out. I think that some of these changes are not specific for macos and they might eventually be required in other platforms, so it might make sense to move the changes to another JIRA if this one doesn't make it.
          Hide
          Flavio Junqueira added a comment -

          yeah, I'm not sure. as far as I can tell, they are all ports of gnu tools to mac os x. for example, make --help:

          ...
          This program built for i386-apple-darwin11.3.0
          Report bugs to <bug-make@gnu.org>
          

          autoreconf

          ...
          Report bugs to <bug-autoconf@gnu.org>.
          GNU Autoconf home page: <http://www.gnu.org/software/autoconf/>.
          General help using GNU software: <http://www.gnu.org/gethelp/>.
          
          Show
          Flavio Junqueira added a comment - yeah, I'm not sure. as far as I can tell, they are all ports of gnu tools to mac os x. for example, make --help: ... This program built for i386-apple-darwin11.3.0 Report bugs to <bug-make@gnu.org> autoreconf ... Report bugs to <bug-autoconf@gnu.org>. GNU Autoconf home page: <http://www.gnu.org/software/autoconf/>. General help using GNU software: <http://www.gnu.org/gethelp/>.
          Hide
          Germán Blanco added a comment -

          I am using the GNU utilities. Are you? I think the only non-GNU tool that I used was "ld". The warnings don't seem difficult to avoid, though, I can give it a try this evening.

          Regarding the wrappers.opt and wrappers-mt.opt files, the reference to those should be removed in the patch.

          Show
          Germán Blanco added a comment - I am using the GNU utilities. Are you? I think the only non-GNU tool that I used was "ld". The warnings don't seem difficult to avoid, though, I can give it a try this evening. Regarding the wrappers.opt and wrappers-mt.opt files, the reference to those should be removed in the patch.
          Hide
          Flavio Junqueira added a comment - - edited

          The patch for 3.4 seems to work fine, just a couple of things I wanted to run by you. When I run autoreconf, I'm getting a bunch warnings:

          Makefile.am:81: warning: wildcard ${srcdir}/tests/*.cc: non-POSIX variable name
          Makefile.am:81: (probably a GNU make extension)
          Makefile.am:81: warning: wildcard ${srcdir}/tests/*.h: non-POSIX variable name
          Makefile.am:81: (probably a GNU make extension)
          Makefile.am:92: warning: shell cat ${srcdir}/tests/wrappers.opt: non-POSIX variable name
          Makefile.am:92: (probably a GNU make extension)
          Makefile.am:105: warning: shell cat ${srcdir}/tests/wrappers-mt.opt: non-POSIX variable name
          Makefile.am:105: (probably a GNU make extension)
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libhashtable.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:16:   while processing Libtool library 'libhashtable.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkmt.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:48:   while processing Libtool library 'libzkmt.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkmt_test.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:16:   while processing Libtool library 'libzkmt_test.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkst.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:16:   while processing Libtool library 'libzkst.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkst_test.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:16:   while processing Libtool library 'libzkst_test.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzookeeper_mt.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:53:   while processing Libtool library 'libzookeeper_mt.la'
          /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzookeeper_st.la': linking libtool libraries using a non-POSIX
          /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac'
          Makefile.am:35:   while processing Libtool library 'libzookeeper_st.la'
          

          Is this expected?

          Also, there are these two error messages that seem to be harmless, but they are there:

          cat: ./tests/wrappers.opt: No such file or directory
          cat: ./tests/wrappers-mt.opt: No such file or directory
          
          Show
          Flavio Junqueira added a comment - - edited The patch for 3.4 seems to work fine, just a couple of things I wanted to run by you. When I run autoreconf, I'm getting a bunch warnings: Makefile.am:81: warning: wildcard ${srcdir}/tests/*.cc: non-POSIX variable name Makefile.am:81: (probably a GNU make extension) Makefile.am:81: warning: wildcard ${srcdir}/tests/*.h: non-POSIX variable name Makefile.am:81: (probably a GNU make extension) Makefile.am:92: warning: shell cat ${srcdir}/tests/wrappers.opt: non-POSIX variable name Makefile.am:92: (probably a GNU make extension) Makefile.am:105: warning: shell cat ${srcdir}/tests/wrappers-mt.opt: non-POSIX variable name Makefile.am:105: (probably a GNU make extension) /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libhashtable.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:16: while processing Libtool library 'libhashtable.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkmt.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:48: while processing Libtool library 'libzkmt.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkmt_test.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:16: while processing Libtool library 'libzkmt_test.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkst.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:16: while processing Libtool library 'libzkst.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzkst_test.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:16: while processing Libtool library 'libzkst_test.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzookeeper_mt.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:53: while processing Libtool library 'libzookeeper_mt.la' /opt/local/share/automake-1.13/am/ltlibrary.am: warning: 'libzookeeper_st.la': linking libtool libraries using a non-POSIX /opt/local/share/automake-1.13/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Makefile.am:35: while processing Libtool library 'libzookeeper_st.la' Is this expected? Also, there are these two error messages that seem to be harmless, but they are there: cat: ./tests/wrappers.opt: No such file or directory cat: ./tests/wrappers-mt.opt: No such file or directory
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12613870/ZOOKEEPER-1742.patch
          against trunk revision 1541810.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 24 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12613870/ZOOKEEPER-1742.patch against trunk revision 1541810. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 24 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1766//console This message is automatically generated.
          Hide
          Germán Blanco added a comment -

          This seems to work in Ubuntu and for me ZCONNECTIONLOSS and no messages sent sounds even nicer than the previous values in testCloseUnconnected1.
          Can anybody please tell why the values were ZOK and 1?

          Show
          Germán Blanco added a comment - This seems to work in Ubuntu and for me ZCONNECTIONLOSS and no messages sent sounds even nicer than the previous values in testCloseUnconnected1. Can anybody please tell why the values were ZOK and 1?
          Hide
          Flavio Junqueira added a comment -

          Ok, I'm hearing two options:

          1. We disable tests
          2. We leave as is

          The problem with the second option is that it is preventing me from running tests altogether on mac os for the C client. Do you think you can propose a patch, Benjamin Reed?

          Show
          Flavio Junqueira added a comment - Ok, I'm hearing two options: We disable tests We leave as is The problem with the second option is that it is preventing me from running tests altogether on mac os for the C client. Do you think you can propose a patch, Benjamin Reed ?
          Hide
          Benjamin Reed added a comment -

          doing the tests on mac osx is hard because the linker does not have the functionality that we need to hook into the mock framework. it's only a subset of the tests, so we would still have some coverage on osx. to really fix it we should probably move to a robust cross-platform mock framework.

          Show
          Benjamin Reed added a comment - doing the tests on mac osx is hard because the linker does not have the functionality that we need to hook into the mock framework. it's only a subset of the tests, so we would still have some coverage on osx. to really fix it we should probably move to a robust cross-platform mock framework.
          Hide
          Patrick Hunt added a comment -

          They are running on Ubuntu fine now, is it right?

          correct in my case (ubuntu 13.10)

          Show
          Patrick Hunt added a comment - They are running on Ubuntu fine now, is it right? correct in my case (ubuntu 13.10)
          Hide
          Flavio Junqueira added a comment -

          If we disable the tests for on Mac OS, aren't we exposing ourselves to trouble? The tests are there for a reason, but granted that I can't remember what these tests are doing, so it is not clear how critical it is that we run them on Mac OS.

          Just so that I understand, trying to fix the tests so that they run on Mac OS would be hard? They are running on Ubuntu fine now, is it right?

          Show
          Flavio Junqueira added a comment - If we disable the tests for on Mac OS, aren't we exposing ourselves to trouble? The tests are there for a reason, but granted that I can't remember what these tests are doing, so it is not clear how critical it is that we run them on Mac OS. Just so that I understand, trying to fix the tests so that they run on Mac OS would be hard? They are running on Ubuntu fine now, is it right?
          Hide
          Benjamin Reed added a comment -

          i propose that i open up another issue to not build these tests on the Mac and do a patch there and then lower the priority of this issue. does that sound ok?

          Show
          Benjamin Reed added a comment - i propose that i open up another issue to not build these tests on the Mac and do a patch there and then lower the priority of this issue. does that sound ok?
          Hide
          Germán Blanco added a comment -

          Sorry but I can't help any more here.
          So far I haven't looked into the C code at all, and I think it would take me around a month to figure out what is going on. On top of that I don't have easy access to a Mac.

          Show
          Germán Blanco added a comment - Sorry but I can't help any more here. So far I haven't looked into the C code at all, and I think it would take me around a month to figure out what is going on. On top of that I don't have easy access to a Mac.
          Hide
          Flavio Junqueira added a comment -

          Benjamin Reed, Germán Blanco, do you guys think there is any chance we can try to fix this issue for 3.4.6? I'd really like to have this in for 3.4.6.

          Show
          Flavio Junqueira added a comment - Benjamin Reed , Germán Blanco , do you guys think there is any chance we can try to fix this issue for 3.4.6? I'd really like to have this in for 3.4.6.
          Hide
          Benjamin Reed added a comment -

          i'm getting failures in osx as well:

          zktest-st:
          tests/TestOperations.cc:270: Assertion: equality assertion failed [Expected: 1, Actual : 0]
          tests/TestOperations.cc:339: Assertion: assertion failed [Expression: timeMock==zh->last_recv]
          tests/TestOperations.cc:407: Assertion: equality assertion failed [Expected: 1, Actual : 0]
          tests/TestOperations.cc:212: Assertion: equality assertion failed [Expected: -7, Actual : 0]
          tests/TestZookeeperClose.cc:128: Assertion: equality assertion failed [Expected: 0, Actual : -4]
          Failures !!!
          Run: 33 Failure total: 5 Failures: 5 Errors: 0

          zktest-mt:
          everything works

          Show
          Benjamin Reed added a comment - i'm getting failures in osx as well: zktest-st: tests/TestOperations.cc:270: Assertion: equality assertion failed [Expected: 1, Actual : 0] tests/TestOperations.cc:339: Assertion: assertion failed [Expression: timeMock==zh->last_recv] tests/TestOperations.cc:407: Assertion: equality assertion failed [Expected: 1, Actual : 0] tests/TestOperations.cc:212: Assertion: equality assertion failed [Expected: -7, Actual : 0] tests/TestZookeeperClose.cc:128: Assertion: equality assertion failed [Expected: 0, Actual : -4] Failures !!! Run: 33 Failure total: 5 Failures: 5 Errors: 0 zktest-mt: everything works
          Hide
          Germán Blanco added a comment -

          The test cases that fail in Linux must be related with the patch, since it is the only thing changed and the test cases passed without the patch. They don't look directly related with the changes, though. That is, at a first sight, they don't look like failures related with the counters that are updated in the functions that are wrapped. So it is probably some side effect, or an error in my changes.
          My guess about the test cases that fail in Mac and don't fail in Linux is that they are related with the new environment. That could be libraries, compiler, operating system or any other part that is new; and it could be generic to all macos users or specific to the environment that I used (Mac OSX 10.8.5, gcc 4.7.3). If anybody else has access to a mac, we can see if it fails in the same test cases or not, maybe that helps.

          Show
          Germán Blanco added a comment - The test cases that fail in Linux must be related with the patch, since it is the only thing changed and the test cases passed without the patch. They don't look directly related with the changes, though. That is, at a first sight, they don't look like failures related with the counters that are updated in the functions that are wrapped. So it is probably some side effect, or an error in my changes. My guess about the test cases that fail in Mac and don't fail in Linux is that they are related with the new environment. That could be libraries, compiler, operating system or any other part that is new; and it could be generic to all macos users or specific to the environment that I used (Mac OSX 10.8.5, gcc 4.7.3). If anybody else has access to a mac, we can see if it fails in the same test cases or not, maybe that helps.
          Hide
          Flavio Junqueira added a comment -

          That's odd... Do you think the test failures are related to your patch?

          Show
          Flavio Junqueira added a comment - That's odd... Do you think the test failures are related to your patch?
          Hide
          Germán Blanco added a comment -

          The patch for branch 3.4 is attached.
          Unfortunatelly, it doesn't look good either.
          It fails in one other test case in Linux, also in the single threaded test:

          tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual  : -4]
          tests/TestClient.cc:363: Assertion: equality assertion failed [Expected: -101, Actual  : -4]
          

          and the same test cases in Mac, although with a different message for the one in the multithreaded case:

          tests/TestZookeeperClose.cc:385: Assertion: equality assertion failed [Expected: 1, Actual  : 0]
          
          Show
          Germán Blanco added a comment - The patch for branch 3.4 is attached. Unfortunatelly, it doesn't look good either. It fails in one other test case in Linux, also in the single threaded test: tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual : -4] tests/TestClient.cc:363: Assertion: equality assertion failed [Expected: -101, Actual : -4] and the same test cases in Mac, although with a different message for the one in the multithreaded case: tests/TestZookeeperClose.cc:385: Assertion: equality assertion failed [Expected: 1, Actual : 0]
          Hide
          Germán Blanco added a comment -

          I will prepare the patch for branch 3.4. It will be interesting to see if passes a different set of test cases there.

          Show
          Germán Blanco added a comment - I will prepare the patch for branch 3.4. It will be interesting to see if passes a different set of test cases there.
          Hide
          Flavio Junqueira added a comment -

          "make test" for me still fails because of the --wrap option. I tried German's patch but it doesn't apply to b3.4.

          Show
          Flavio Junqueira added a comment - "make test" for me still fails because of the --wrap option. I tried German's patch but it doesn't apply to b3.4.
          Hide
          Patrick Hunt added a comment -

          With ZOOKEEPER-1646 and ZOOKEEPER-1795 fixed the c client tests are passing for me on Ubuntu Raring on both branch-3.4 and trunk.

          Show
          Patrick Hunt added a comment - With ZOOKEEPER-1646 and ZOOKEEPER-1795 fixed the c client tests are passing for me on Ubuntu Raring on both branch-3.4 and trunk.
          Hide
          Germán Blanco added a comment -

          Last comment was not complete. It fails in that test case both in Mac and Linux, but it fails in more test cases in Mac:

          tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual  : -4]
          tests/TestOperations.cc:270: Assertion: equality assertion failed [Expected: 1, Actual  : 0]
          tests/TestOperations.cc:339: Assertion: assertion failed [Expression: timeMock==zh->last_recv]
          tests/TestOperations.cc:407: Assertion: equality assertion failed [Expected: 1, Actual  : 0]
          tests/TestOperations.cc:212: Assertion: equality assertion failed [Expected: -7, Actual  : 0]
          Failures !!!
          Run: 41   Failure total: 5   Failures: 5   Errors: 0
          
          FAIL: zktest-mt
          ===============
          
           ZooKeeper server startedRunning 
          .
          .
          .
          Zookeeper_close::testCloseUnconnected1 : elapsed 87 : OK
          Zookeeper_close::testCloseConnected1Assertion failed: (cptr), function zookeeper_process, file src/zookeeper.c, line 2649.
          
          Show
          Germán Blanco added a comment - Last comment was not complete. It fails in that test case both in Mac and Linux, but it fails in more test cases in Mac: tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual : -4] tests/TestOperations.cc:270: Assertion: equality assertion failed [Expected: 1, Actual : 0] tests/TestOperations.cc:339: Assertion: assertion failed [Expression: timeMock==zh->last_recv] tests/TestOperations.cc:407: Assertion: equality assertion failed [Expected: 1, Actual : 0] tests/TestOperations.cc:212: Assertion: equality assertion failed [Expected: -7, Actual : 0] Failures !!! Run: 41 Failure total: 5 Failures: 5 Errors: 0 FAIL: zktest-mt =============== ZooKeeper server startedRunning . . . Zookeeper_close::testCloseUnconnected1 : elapsed 87 : OK Zookeeper_close::testCloseConnected1Assertion failed: (cptr), function zookeeper_process, file src/zookeeper.c, line 2649.
          Hide
          Germán Blanco added a comment -

          With the attached patch, the build in mac os works.
          However, it fails in a test case:
          tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual : -4]
          Both in Mac and Linux. I can't figure out why, so I am leaving it here. I hope this is of any help.

          Show
          Germán Blanco added a comment - With the attached patch, the build in mac os works. However, it fails in a test case: tests/TestZookeeperClose.cc:127: Assertion: equality assertion failed [Expected: 0, Actual : -4] Both in Mac and Linux. I can't figure out why, so I am leaving it here. I hope this is of any help.
          Hide
          Patrick Hunt added a comment -

          Sounds good, here: ZOOKEEPER-1795

          Show
          Patrick Hunt added a comment - Sounds good, here: ZOOKEEPER-1795
          Hide
          Benjamin Reed added a comment -

          @pat you should split out the ubuntu build problem. there are just some unistd.h includes missing

          Show
          Benjamin Reed added a comment - @pat you should split out the ubuntu build problem. there are just some unistd.h includes missing
          Hide
          Benjamin Reed added a comment -

          the --wrap is only used with the tests, so it shouldn't be a problem in general. i think the reason the dlsym isn't working is because we are linking with the static libraries as you mention. we should really be linking to the shared libraries.

          Show
          Benjamin Reed added a comment - the --wrap is only used with the tests, so it shouldn't be a problem in general. i think the reason the dlsym isn't working is because we are linking with the static libraries as you mention. we should really be linking to the shared libraries.
          Hide
          Germán Blanco added a comment -

          More specifically, what I am worrying about is that the linker option --wrap might replace not only the function calls within the zookeeper code but also other calls to these functions in e.g. the shared libraries.

          Show
          Germán Blanco added a comment - More specifically, what I am worrying about is that the linker option --wrap might replace not only the function calls within the zookeeper code but also other calls to these functions in e.g. the shared libraries.
          Hide
          Germán Blanco added a comment -

          I need a bit of help here.
          I have tried using dlsym instead of the --wrap linker option, but I found an error when doing it. It is most likely due to the corresponding shared library not being loaded in memory when calling dlsym. I will need to look it up, unless there is a different way to solve this ...
          The dlsym method will not work for the functions that are not in shared libraries (e.g. deliverWatchers), and for those I was thinking in using a new macro and compiling a new version of the libraries for use only in test. In that new version of the library, all the calls to functions that are now wrapped will have "wrap_" appended to their name. The wrapper function in the test code will have this name ("wrap_" appended) and call the original function.
          Will that work for all functions? That means, also for those that are now wrapped but are not part of the zookeeper library code (e.g. calloc).
          If that works, then I would use the same method for all those wrapped functions, and this method is portable to all platforms.
          Can anybody please answer this question?

          Show
          Germán Blanco added a comment - I need a bit of help here. I have tried using dlsym instead of the --wrap linker option, but I found an error when doing it. It is most likely due to the corresponding shared library not being loaded in memory when calling dlsym. I will need to look it up, unless there is a different way to solve this ... The dlsym method will not work for the functions that are not in shared libraries (e.g. deliverWatchers), and for those I was thinking in using a new macro and compiling a new version of the libraries for use only in test. In that new version of the library, all the calls to functions that are now wrapped will have "wrap_" appended to their name. The wrapper function in the test code will have this name ("wrap_" appended) and call the original function. Will that work for all functions? That means, also for those that are now wrapped but are not part of the zookeeper library code (e.g. calloc). If that works, then I would use the same method for all those wrapped functions, and this method is portable to all platforms. Can anybody please answer this question?
          Hide
          Germán Blanco added a comment -

          I will give it a try, it will take around a week though.
          The current test programs for the C API are linked to the same library that is part of the release, that is the library that is used for the client applications. In order for the test to work without the wrap option, one possibility would be to create a different library with just a few function names changed (those functions that are now wrapped) and use this library only for the test programs.
          If I find out how to link the test programs with the shared library version instead of the static library maybe that wouldn't be necessary. If anybody can tell me how to do that, please do.

          Show
          Germán Blanco added a comment - I will give it a try, it will take around a week though. The current test programs for the C API are linked to the same library that is part of the release, that is the library that is used for the client applications. In order for the test to work without the wrap option, one possibility would be to create a different library with just a few function names changed (those functions that are now wrapped ) and use this library only for the test programs. If I find out how to link the test programs with the shared library version instead of the static library maybe that wouldn't be necessary. If anybody can tell me how to do that, please do.
          Hide
          Flavio Junqueira added a comment -

          Germán Blanco, do you think you can generate a patch? I'm also not sure what you mean with using a different version of the zookeeper library for the tests.

          Show
          Flavio Junqueira added a comment - Germán Blanco , do you think you can generate a patch? I'm also not sure what you mean with using a different version of the zookeeper library for the tests.
          Hide
          Germán Blanco added a comment -

          I think I could fix the "ld -wrap" option issue in Mac OSX. There is a proposal here:
          https://discussions.apple.com/thread/617779?start=0&tstart=0
          I have already tried this in Utils.h, and it works for external functions (those that are not defined in the zookeeper library):

          #define DECLARE_WRAPPER(ret,sym,sig) \
              typedef ret (*fptr_##sym) sig; extern "C" ret sym sig
          #define CALL_REAL(sym,params) \
              (*((fptr_##sym)dlsym(RTLD_NEXT, "sym"))) params
          

          For the functions in the zookeeper library that are wrapped, the easiest solution for me would be to use a different version of the zookeeper library for the tests, changing the name of these functions.

          Show
          Germán Blanco added a comment - I think I could fix the "ld -wrap" option issue in Mac OSX. There is a proposal here: https://discussions.apple.com/thread/617779?start=0&tstart=0 I have already tried this in Utils.h, and it works for external functions (those that are not defined in the zookeeper library): #define DECLARE_WRAPPER(ret,sym,sig) \ typedef ret (*fptr_##sym) sig; extern "C" ret sym sig #define CALL_REAL(sym,params) \ (*((fptr_##sym)dlsym(RTLD_NEXT, "sym"))) params For the functions in the zookeeper library that are wrapped, the easiest solution for me would be to use a different version of the zookeeper library for the tests, changing the name of these functions.
          Hide
          Patrick Hunt added a comment -

          Should we split these out? How do you want to handle it? The failing test is a blocker for 3.4.6 IMO.

          Show
          Patrick Hunt added a comment - Should we split these out? How do you want to handle it? The failing test is a blocker for 3.4.6 IMO.
          Hide
          Patrick Hunt added a comment -

          Also I'm seeing this fail consistently in branch34

          Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: tests/ZKMocks.cc:271: SyncedBoolCondition DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed.
          
          Show
          Patrick Hunt added a comment - Also I'm seeing this fail consistently in branch34 Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: tests/ZKMocks.cc:271: SyncedBoolCondition DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed.
          Hide
          Patrick Hunt added a comment -

          Seems there is an issue as well for Ubuntu (I'm on 13.04), however I'm only seeing it on trunk and not branch 34

          make check
          make  zktest-st zktest-mt
          make[1]: Entering directory `/home/phunt/dev/svn/svn-zookeeper/src/c'
          g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated  -DUSE_STATIC_LIB -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED -g -O2 -MT zktest_st-TestReconfigServer.o -MD -MP -MF .deps/zktest_st-TestReconfigServer.Tpo -c -o zktest_st-TestReconfigServer.o `test -f 'tests/TestReconfigServer.cc' || echo './'`tests/TestReconfigServer.cc
          tests/TestReconfigServer.cc: In member function ‘bool TestReconfigServer::waitForConnected(zhandle_t*, uint32_t)’:
          tests/TestReconfigServer.cc:128:16: error: ‘sleep’ was not declared in this scope
          make[1]: *** [zktest_st-TestReconfigServer.o] Error 1
          make[1]: Leaving directory `/home/phunt/dev/svn/svn-zookeeper/src/c'
          make: *** [check-am] Error 2
          

          I have

          g++ --version
          g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
          Copyright (C) 2012 Free Software Foundation, Inc.
          This is free software; see the source for copying conditions.  There is NO
          warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
          
          Show
          Patrick Hunt added a comment - Seems there is an issue as well for Ubuntu (I'm on 13.04), however I'm only seeing it on trunk and not branch 34 make check make zktest-st zktest-mt make[1]: Entering directory `/home/phunt/dev/svn/svn-zookeeper/src/c' g++ -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -DUSE_STATIC_LIB -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED -g -O2 -MT zktest_st-TestReconfigServer.o -MD -MP -MF .deps/zktest_st-TestReconfigServer.Tpo -c -o zktest_st-TestReconfigServer.o `test -f 'tests/TestReconfigServer.cc' || echo './'`tests/TestReconfigServer.cc tests/TestReconfigServer.cc: In member function ‘bool TestReconfigServer::waitForConnected(zhandle_t*, uint32_t)’: tests/TestReconfigServer.cc:128:16: error: ‘sleep’ was not declared in this scope make[1]: *** [zktest_st-TestReconfigServer.o] Error 1 make[1]: Leaving directory `/home/phunt/dev/svn/svn-zookeeper/src/c' make: *** [check-am] Error 2 I have g++ --version g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
          Hide
          Flavio Junqueira added a comment -

          We can build the C client, but we can't run tests. At least I couldn't make it work on my computer, but I haven't had the time to look into it again.

          Show
          Flavio Junqueira added a comment - We can build the C client, but we can't run tests. At least I couldn't make it work on my computer, but I haven't had the time to look into it again.
          Hide
          Patrick Hunt added a comment -

          Does this mean that we can't compile the c client on macos? If so we should increase the priority IMO.

          Show
          Patrick Hunt added a comment - Does this mean that we can't compile the c client on macos? If so we should increase the priority IMO.

            People

            • Assignee:
              Germán Blanco
              Reporter:
              Flavio Junqueira
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development