Re: Native client on MacOS and Windows?

[Damien Diederen]

Hi Máté, Deepak,

> Also we had a recent discussion with Damien (@ztzg) and it turned out that
> the SASL is also not supported by the C-client on windows. The Cyrus SASL
> official page (https://www.cyrusimap.org/sasl/sasl/windows.html) says:
> "Note, that Cyrus SASL on Windows is still laregely a “work in progress”. ".

A tad off-topic, but FYI: this is indeed what the page says, but I have
dug a bit deeper on that front—and it turns out that Sergey Ilinykh has
published a bunch of "Conan" build files for the Cyrus library and its
dependencies, so SASL in the Windows C client may soon become a reality:

https://bintray.com/rion/common

Cheers, -D



Mate Szalay-Beko  writes:
> I compiled and tested manually the C-client on windows recently (in
> relation to adding SSL support). As far as I can tell, the unit tests are
> not working on windows at the moment, however it shouldn't be a big deal to
> make them work. But some scripts definitely will need to be re-implemented
> for windows, like those which generates the test SSL certificates and in
> general starts the ZooKeeper servers for the tests.
>
> Also we had a recent discussion with Damien (@ztzg) and it turned out that
> the SASL is also not supported by the C-client on windows. The Cyrus SASL
> official page (https://www.cyrusimap.org/sasl/sasl/windows.html) says:
> "Note, that Cyrus SASL on Windows is still laregely a “work in progress”. ".
>
> In general I don't really know of anyone who would use the native C-client
> on windows or on mac in production.
> To make it work on mac for development makes more sense I think. However,
> for my needs I am quite happy with the docker-based development as well.
>
> Cheers,
> Mate
>
> On Mon, Nov 25, 2019 at 7:42 PM deepak  wrote:
>
>> Hi Enrico,
>>
>> I am able to build the native client on Windows, but it seems like there
>> are not tests configured in the VC project?
>> Could you please point me to the jenkins job you're referring to? I'd be
>> curious to see how it's setup.
>>
>> In any case, the official support matrix
>> <
>> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
>> >
>> claims the native client is not supported on Windows.  My intention with
>> this thread was to find out if there are users in the community who are
>> running the native client on Windows in production.  Knowing there are some
>> such users would give us confidence if we were to move forward with it.
>> Part of the challenge is we need to account for commitment from our team to
>> investigate and fix/work around any issues that we may encounter with the
>> native client on Windows.

Re: Native client on MacOS and Windows?

[Mate Szalay-Beko]

I compiled and tested manually the C-client on windows recently (in
relation to adding SSL support). As far as I can tell, the unit tests are
not working on windows at the moment, however it shouldn't be a big deal to
make them work. But some scripts definitely will need to be re-implemented
for windows, like those which generates the test SSL certificates and in
general starts the ZooKeeper servers for the tests.

Also we had a recent discussion with Damien (@ztzg) and it turned out that
the SASL is also not supported by the C-client on windows. The Cyrus SASL
official page (https://www.cyrusimap.org/sasl/sasl/windows.html) says:
"Note, that Cyrus SASL on Windows is still laregely a “work in progress”. ".

In general I don't really know of anyone who would use the native C-client
on windows or on mac in production.
To make it work on mac for development makes more sense I think. However,
for my needs I am quite happy with the docker-based development as well.

Cheers,
Mate

On Mon, Nov 25, 2019 at 7:42 PM deepak  wrote:

> Hi Enrico,
>
> I am able to build the native client on Windows, but it seems like there
> are not tests configured in the VC project?
> Could you please point me to the jenkins job you're referring to? I'd be
> curious to see how it's setup.
>
> In any case, the official support matrix
> <
> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
> >
> claims the native client is not supported on Windows.  My intention with
> this thread was to find out if there are users in the community who are
> running the native client on Windows in production.  Knowing there are some
> such users would give us confidence if we were to move forward with it.
> Part of the challenge is we need to account for commitment from our team to
> investigate and fix/work around any issues that we may encounter with the
> native client on Windows.
>
> --
> Deepak
>
> On Sat, Nov 23, 2019 at 1:13 AM Enrico Olivelli 
> wrote:
>
> > Il sab 23 nov 2019, 04:42 deepak  ha scritto:
> >
> > > Hi Andor,
> > >
> > > MacOS support would be great from a developer convenience perspective -
> > > this would enable us to implement our application (that interacts with
> > > ZooKeeper) in a test-driven way.  From a software development
> > perspective,
> > > it would be great if we are able to run all the ZooKeeper native client
> > > tests, and also all of our application level unit / integration tests
> > > locally on MacOS before pushing out the changes to source control
> > > repository.
> > >
> > > We could use Linux to develop our application due to this limitation,
> > which
> > > would be a minor inconvenience.
> > >
> > > Lack of Windows support is a little more disappointing.
> >
> >
> > We have a Job on jenkins that builds zk client on windows.
> > I thought the client was working on windows.
> >
> > For MacOs, can we try to enable it?
> >
> > Enrico
> >
> >
> >
> > This would mean we
> > > can't support features that rely on ZooKeeper for the Windows version
> of
> > > our application.  I do not see an easy way around this.  etcd seems to
> > > support a limited set of APIs through HTTP
> > > , and there is also the full-fledged
> > > support for gRPC
> > > <
> >
> https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api.md
> > > >
> > > - both of which allow for possibilities to integrate a native C/C++
> > > application with etcd.  Whereas with ZooKeeper, the only viable option
> I
> > > see (to support a native C/C++ application on Windows) is to use JNI
> > (with
> > > which I have limited experience, but seems like this may work).
> > >
> > > --
> > > Deepak
> > >
> > > On Fri, Nov 22, 2019 at 4:12 AM Andor Molnar  wrote:
> > >
> > > > Hi deepak,
> > > >
> > > > I’m trying to refresh my memory about this. I think I’ve given up
> > > building
> > > > on MacOS, because when we call the linker at the end of the
> > compilation,
> > > we
> > > > call it with a parameter which is not supported in OSX’s standard
> > > > toolchain. (Xcode)
> > > >
> > > > Which means I’ve managed to get around with the issue you mentioned,
> > but
> > > I
> > > > can’t recall the details.
> > > >
> > > > Btw I usually use CentOS docker/VM to compile and validate the C
> > client.
> > > > Why do you need native Mac support?
> > > >
> > > > Andor
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On 2019. Nov 6., at 5:11, deepak  wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I see that from the support matrix
> > > > > <
> > > >
> > >
> >
> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
> > > > >that
> > > > > the native client is not supported on Windows and MacOS.  I am
> > curious
> > > to
> > > > > know if anyone has had success in getting it to work on these
> > > platforms?
> > > > > On MacOS, naturally, we are mostly interested in development, and
> on
> > > > > Windows, we would like to use it in production.
> > 

Re: Native client on MacOS and Windows?

[deepak]

Hi Enrico,

I am able to build the native client on Windows, but it seems like there
are not tests configured in the VC project?
Could you please point me to the jenkins job you're referring to? I'd be
curious to see how it's setup.

In any case, the official support matrix

claims the native client is not supported on Windows.  My intention with
this thread was to find out if there are users in the community who are
running the native client on Windows in production.  Knowing there are some
such users would give us confidence if we were to move forward with it.
Part of the challenge is we need to account for commitment from our team to
investigate and fix/work around any issues that we may encounter with the
native client on Windows.

--
Deepak

On Sat, Nov 23, 2019 at 1:13 AM Enrico Olivelli  wrote:

> Il sab 23 nov 2019, 04:42 deepak  ha scritto:
>
> > Hi Andor,
> >
> > MacOS support would be great from a developer convenience perspective -
> > this would enable us to implement our application (that interacts with
> > ZooKeeper) in a test-driven way.  From a software development
> perspective,
> > it would be great if we are able to run all the ZooKeeper native client
> > tests, and also all of our application level unit / integration tests
> > locally on MacOS before pushing out the changes to source control
> > repository.
> >
> > We could use Linux to develop our application due to this limitation,
> which
> > would be a minor inconvenience.
> >
> > Lack of Windows support is a little more disappointing.
>
>
> We have a Job on jenkins that builds zk client on windows.
> I thought the client was working on windows.
>
> For MacOs, can we try to enable it?
>
> Enrico
>
>
>
> This would mean we
> > can't support features that rely on ZooKeeper for the Windows version of
> > our application.  I do not see an easy way around this.  etcd seems to
> > support a limited set of APIs through HTTP
> > , and there is also the full-fledged
> > support for gRPC
> > <
> https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api.md
> > >
> > - both of which allow for possibilities to integrate a native C/C++
> > application with etcd.  Whereas with ZooKeeper, the only viable option I
> > see (to support a native C/C++ application on Windows) is to use JNI
> (with
> > which I have limited experience, but seems like this may work).
> >
> > --
> > Deepak
> >
> > On Fri, Nov 22, 2019 at 4:12 AM Andor Molnar  wrote:
> >
> > > Hi deepak,
> > >
> > > I’m trying to refresh my memory about this. I think I’ve given up
> > building
> > > on MacOS, because when we call the linker at the end of the
> compilation,
> > we
> > > call it with a parameter which is not supported in OSX’s standard
> > > toolchain. (Xcode)
> > >
> > > Which means I’ve managed to get around with the issue you mentioned,
> but
> > I
> > > can’t recall the details.
> > >
> > > Btw I usually use CentOS docker/VM to compile and validate the C
> client.
> > > Why do you need native Mac support?
> > >
> > > Andor
> > >
> > >
> > >
> > >
> > >
> > > > On 2019. Nov 6., at 5:11, deepak  wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I see that from the support matrix
> > > > <
> > >
> >
> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
> > > >that
> > > > the native client is not supported on Windows and MacOS.  I am
> curious
> > to
> > > > know if anyone has had success in getting it to work on these
> > platforms?
> > > > On MacOS, naturally, we are mostly interested in development, and on
> > > > Windows, we would like to use it in production.
> > > >
> > > > At this point, I am hitting compile problems on MacOS (see below for
> > > > details).
> > > >
> > > > On Windows, I was able to run "cmake --build ." successfully, but
> > running
> > > > "ctest -V" gives me "No tests were found!!!".  It seems there are no
> > unit
> > > > tests configured to run on Windows?  Or am I missing something?
> > > >
> > > > PS:
> > > > Compile problems on MacOS:
> > > > zookeeper-client-c$ make check
> > > > /Library/Developer/CommandLineTools/usr/bin/make  zktest-st zktest-mt
> > > > g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated
> > > > -DUSE_STATIC_LIB -I/opt/local/include
> > > > -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED  -g -O2
> -MT
> > > > zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo
> > -c
> > > -o
> > > > zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo
> > > > './'`tests/LibCSymTable.cc
> > > > In file included from tests/LibCSymTable.cc:19:
> > > > ./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t';
> did
> > > you
> > > > mean 'clock_t'?
> > > >DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct
> timespec*));
> > > >   ^
> > > >   

Re: Native client on MacOS and Windows?

[Enrico Olivelli]

Il sab 23 nov 2019, 04:42 deepak  ha scritto:

> Hi Andor,
>
> MacOS support would be great from a developer convenience perspective -
> this would enable us to implement our application (that interacts with
> ZooKeeper) in a test-driven way.  From a software development perspective,
> it would be great if we are able to run all the ZooKeeper native client
> tests, and also all of our application level unit / integration tests
> locally on MacOS before pushing out the changes to source control
> repository.
>
> We could use Linux to develop our application due to this limitation, which
> would be a minor inconvenience.
>
> Lack of Windows support is a little more disappointing.


We have a Job on jenkins that builds zk client on windows.
I thought the client was working on windows.

For MacOs, can we try to enable it?

Enrico



This would mean we
> can't support features that rely on ZooKeeper for the Windows version of
> our application.  I do not see an easy way around this.  etcd seems to
> support a limited set of APIs through HTTP
> , and there is also the full-fledged
> support for gRPC
>  >
> - both of which allow for possibilities to integrate a native C/C++
> application with etcd.  Whereas with ZooKeeper, the only viable option I
> see (to support a native C/C++ application on Windows) is to use JNI (with
> which I have limited experience, but seems like this may work).
>
> --
> Deepak
>
> On Fri, Nov 22, 2019 at 4:12 AM Andor Molnar  wrote:
>
> > Hi deepak,
> >
> > I’m trying to refresh my memory about this. I think I’ve given up
> building
> > on MacOS, because when we call the linker at the end of the compilation,
> we
> > call it with a parameter which is not supported in OSX’s standard
> > toolchain. (Xcode)
> >
> > Which means I’ve managed to get around with the issue you mentioned, but
> I
> > can’t recall the details.
> >
> > Btw I usually use CentOS docker/VM to compile and validate the C client.
> > Why do you need native Mac support?
> >
> > Andor
> >
> >
> >
> >
> >
> > > On 2019. Nov 6., at 5:11, deepak  wrote:
> > >
> > > Hi All,
> > >
> > > I see that from the support matrix
> > > <
> >
> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
> > >that
> > > the native client is not supported on Windows and MacOS.  I am curious
> to
> > > know if anyone has had success in getting it to work on these
> platforms?
> > > On MacOS, naturally, we are mostly interested in development, and on
> > > Windows, we would like to use it in production.
> > >
> > > At this point, I am hitting compile problems on MacOS (see below for
> > > details).
> > >
> > > On Windows, I was able to run "cmake --build ." successfully, but
> running
> > > "ctest -V" gives me "No tests were found!!!".  It seems there are no
> unit
> > > tests configured to run on Windows?  Or am I missing something?
> > >
> > > PS:
> > > Compile problems on MacOS:
> > > zookeeper-client-c$ make check
> > > /Library/Developer/CommandLineTools/usr/bin/make  zktest-st zktest-mt
> > > g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated
> > > -DUSE_STATIC_LIB -I/opt/local/include
> > > -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED  -g -O2 -MT
> > > zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo
> -c
> > -o
> > > zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo
> > > './'`tests/LibCSymTable.cc
> > > In file included from tests/LibCSymTable.cc:19:
> > > ./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t'; did
> > you
> > > mean 'clock_t'?
> > >DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct timespec*));
> > >   ^
> > >   clock_t
> > > ./tests/LibCSymTable.h:51:29: note: expanded from macro 'DECLARE_SYM'
> > >typedef ret (*sym##_sig)sig; \
> > >^
> > > /usr/include/sys/_types/_clock_t.h:31:33: note: 'clock_t' declared here
> > > typedef __darwin_clock_tclock_t;
> > >^
> > > 1 error generated.
> > > make[1]: *** [zktest_st-LibCSymTable.o] Error 1
> > > make: *** [check-am] Error 2
> > >
> > > Trying to work around this by using "clock_t" instead of "clockid_t", I
> > get
> > > past this to hit this next error:
> > >
> > > [...snip...]
> > > In file included from tests/TestZookeeperInit.cc:19:
> > > In file included from
> > > /opt/local/include/cppunit/extensions/HelperMacros.h:9:
> > > /opt/local/include/cppunit/TestCaller.h:121:28: error: no member named
> > > 'bind' in namespace 'std';
> > >  did you mean 'find'?
> > >m_test_function( std::bind(test, m_fixture) )
> > > ~^~~~
> > >  find
> >
> >
>

Re: Native client on MacOS and Windows?

[deepak]

Hi Andor,

MacOS support would be great from a developer convenience perspective -
this would enable us to implement our application (that interacts with
ZooKeeper) in a test-driven way.  From a software development perspective,
it would be great if we are able to run all the ZooKeeper native client
tests, and also all of our application level unit / integration tests
locally on MacOS before pushing out the changes to source control
repository.

We could use Linux to develop our application due to this limitation, which
would be a minor inconvenience.

Lack of Windows support is a little more disappointing.  This would mean we
can't support features that rely on ZooKeeper for the Windows version of
our application.  I do not see an easy way around this.  etcd seems to
support a limited set of APIs through HTTP
, and there is also the full-fledged
support for gRPC

- both of which allow for possibilities to integrate a native C/C++
application with etcd.  Whereas with ZooKeeper, the only viable option I
see (to support a native C/C++ application on Windows) is to use JNI (with
which I have limited experience, but seems like this may work).

--
Deepak

On Fri, Nov 22, 2019 at 4:12 AM Andor Molnar  wrote:

> Hi deepak,
>
> I’m trying to refresh my memory about this. I think I’ve given up building
> on MacOS, because when we call the linker at the end of the compilation, we
> call it with a parameter which is not supported in OSX’s standard
> toolchain. (Xcode)
>
> Which means I’ve managed to get around with the issue you mentioned, but I
> can’t recall the details.
>
> Btw I usually use CentOS docker/VM to compile and validate the C client.
> Why do you need native Mac support?
>
> Andor
>
>
>
>
>
> > On 2019. Nov 6., at 5:11, deepak  wrote:
> >
> > Hi All,
> >
> > I see that from the support matrix
> > <
> http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supportedPlatforms
> >that
> > the native client is not supported on Windows and MacOS.  I am curious to
> > know if anyone has had success in getting it to work on these platforms?
> > On MacOS, naturally, we are mostly interested in development, and on
> > Windows, we would like to use it in production.
> >
> > At this point, I am hitting compile problems on MacOS (see below for
> > details).
> >
> > On Windows, I was able to run "cmake --build ." successfully, but running
> > "ctest -V" gives me "No tests were found!!!".  It seems there are no unit
> > tests configured to run on Windows?  Or am I missing something?
> >
> > PS:
> > Compile problems on MacOS:
> > zookeeper-client-c$ make check
> > /Library/Developer/CommandLineTools/usr/bin/make  zktest-st zktest-mt
> > g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated
> > -DUSE_STATIC_LIB -I/opt/local/include
> > -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED  -g -O2 -MT
> > zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo -c
> -o
> > zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo
> > './'`tests/LibCSymTable.cc
> > In file included from tests/LibCSymTable.cc:19:
> > ./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t'; did
> you
> > mean 'clock_t'?
> >DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct timespec*));
> >   ^
> >   clock_t
> > ./tests/LibCSymTable.h:51:29: note: expanded from macro 'DECLARE_SYM'
> >typedef ret (*sym##_sig)sig; \
> >^
> > /usr/include/sys/_types/_clock_t.h:31:33: note: 'clock_t' declared here
> > typedef __darwin_clock_tclock_t;
> >^
> > 1 error generated.
> > make[1]: *** [zktest_st-LibCSymTable.o] Error 1
> > make: *** [check-am] Error 2
> >
> > Trying to work around this by using "clock_t" instead of "clockid_t", I
> get
> > past this to hit this next error:
> >
> > [...snip...]
> > In file included from tests/TestZookeeperInit.cc:19:
> > In file included from
> > /opt/local/include/cppunit/extensions/HelperMacros.h:9:
> > /opt/local/include/cppunit/TestCaller.h:121:28: error: no member named
> > 'bind' in namespace 'std';
> >  did you mean 'find'?
> >m_test_function( std::bind(test, m_fixture) )
> > ~^~~~
> >  find
>
>

Re: Native client on MacOS and Windows?

[Andor Molnar]

Hi deepak,

I’m trying to refresh my memory about this. I think I’ve given up building on 
MacOS, because when we call the linker at the end of the compilation, we call 
it with a parameter which is not supported in OSX’s standard toolchain. (Xcode)

Which means I’ve managed to get around with the issue you mentioned, but I 
can’t recall the details.

Btw I usually use CentOS docker/VM to compile and validate the C client. Why do 
you need native Mac support?

Andor





> On 2019. Nov 6., at 5:11, deepak  wrote:
> 
> Hi All,
> 
> I see that from the support matrix
> that
> the native client is not supported on Windows and MacOS.  I am curious to
> know if anyone has had success in getting it to work on these platforms?
> On MacOS, naturally, we are mostly interested in development, and on
> Windows, we would like to use it in production.
> 
> At this point, I am hitting compile problems on MacOS (see below for
> details).
> 
> On Windows, I was able to run "cmake --build ." successfully, but running
> "ctest -V" gives me "No tests were found!!!".  It seems there are no unit
> tests configured to run on Windows?  Or am I missing something?
> 
> PS:
> Compile problems on MacOS:
> zookeeper-client-c$ make check
> /Library/Developer/CommandLineTools/usr/bin/make  zktest-st zktest-mt
> g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated
> -DUSE_STATIC_LIB -I/opt/local/include
> -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED  -g -O2 -MT
> zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo -c -o
> zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo
> './'`tests/LibCSymTable.cc
> In file included from tests/LibCSymTable.cc:19:
> ./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t'; did you
> mean 'clock_t'?
>DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct timespec*));
>   ^
>   clock_t
> ./tests/LibCSymTable.h:51:29: note: expanded from macro 'DECLARE_SYM'
>typedef ret (*sym##_sig)sig; \
>^
> /usr/include/sys/_types/_clock_t.h:31:33: note: 'clock_t' declared here
> typedef __darwin_clock_tclock_t;
>^
> 1 error generated.
> make[1]: *** [zktest_st-LibCSymTable.o] Error 1
> make: *** [check-am] Error 2
> 
> Trying to work around this by using "clock_t" instead of "clockid_t", I get
> past this to hit this next error:
> 
> [...snip...]
> In file included from tests/TestZookeeperInit.cc:19:
> In file included from
> /opt/local/include/cppunit/extensions/HelperMacros.h:9:
> /opt/local/include/cppunit/TestCaller.h:121:28: error: no member named
> 'bind' in namespace 'std';
>  did you mean 'find'?
>m_test_function( std::bind(test, m_fixture) )
> ~^~~~
>  find

Native client on MacOS and Windows?

[deepak]

Hi All,

I see that from the support matrix
that
the native client is not supported on Windows and MacOS.  I am curious to
know if anyone has had success in getting it to work on these platforms?
On MacOS, naturally, we are mostly interested in development, and on
Windows, we would like to use it in production.

At this point, I am hitting compile problems on MacOS (see below for
details).

On Windows, I was able to run "cmake --build ." successfully, but running
"ctest -V" gives me "No tests were found!!!".  It seems there are no unit
tests configured to run on Windows?  Or am I missing something?

PS:
Compile problems on MacOS:
zookeeper-client-c$ make check
/Library/Developer/CommandLineTools/usr/bin/make  zktest-st zktest-mt
g++ -DHAVE_CONFIG_H -I.  -I./include -I./tests -I./generated
-DUSE_STATIC_LIB -I/opt/local/include
-DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED  -g -O2 -MT
zktest_st-LibCSymTable.o -MD -MP -MF .deps/zktest_st-LibCSymTable.Tpo -c -o
zktest_st-LibCSymTable.o `test -f 'tests/LibCSymTable.cc' || echo
'./'`tests/LibCSymTable.cc
In file included from tests/LibCSymTable.cc:19:
./tests/LibCSymTable.h:85:36: error: unknown type name 'clockid_t'; did you
mean 'clock_t'?
DECLARE_SYM(int,clock_gettime,(clockid_t clk_id, struct timespec*));
   ^
   clock_t
./tests/LibCSymTable.h:51:29: note: expanded from macro 'DECLARE_SYM'
typedef ret (*sym##_sig)sig; \
^
/usr/include/sys/_types/_clock_t.h:31:33: note: 'clock_t' declared here
typedef __darwin_clock_tclock_t;
^
1 error generated.
make[1]: *** [zktest_st-LibCSymTable.o] Error 1
make: *** [check-am] Error 2

Trying to work around this by using "clock_t" instead of "clockid_t", I get
past this to hit this next error:

[...snip...]
In file included from tests/TestZookeeperInit.cc:19:
In file included from
/opt/local/include/cppunit/extensions/HelperMacros.h:9:
/opt/local/include/cppunit/TestCaller.h:121:28: error: no member named
'bind' in namespace 'std';
  did you mean 'find'?
m_test_function( std::bind(test, m_fixture) )
 ~^~~~
  find