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 <deepak...@gmail.com> 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 <eolive...@gmail.com> > wrote: > > > Il sab 23 nov 2019, 04:42 deepak <deepak...@gmail.com> 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 > > > <https://etcd.io/docs/v3.4.0/rfc/>, 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 <an...@apache.org> 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 <deepak...@gmail.com> 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_t clock_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 > > > > > > > > > > > > > >
