Thanks for your message. It would be great to roll your CentOS fixes into the sprout codebase - I agree it would be a desirable target.
On the accumulator.cpp error, I think the issue is that cstdatomic defines this method slightly differently to atomic. In atomic, the std::memory_order parameter is optional and defaults to memory_order_seq_cst. Please can you try specifying this explicitly and see if that helps? Thanks, Matt -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 27 August 2013 05:44 To: [email protected] Subject: Re: [Clearwater] compiling from source To answer your last question, I got it to compile and to start up, but the self tests did not run cleanly (one or two of them claimed memory corruption). I put it aside in favor of looking at CentOS, which is a more desirable target in the long run (and probably more interesting to the wider community?) I've not succeeded in compiling on CentOS yet, but am getting closer each time. So far: - sprout/modules/libmemcached/libmemcached/csl/parser.cc needed edits to stop choking on YYENABLE_NLS and YYLTYPE_IS_TRIVIAL. - the #include of <atomic> in sprout/include/sas.h and accumulator.h needed to be changed to <cstdatomic> - connection_pool.cpp, flowtable.cpp and accumulator.cpp needed tweaks to overcome the ambiguity in calls to to_string (eg whether the arg was a unsigned int, long long etc). Currently I'm looking at this error compiling accumulator.cpp: g++ -Wno-write-strings -ggdb3 -std=c++0x g++ -I/home/keller/cw/sprout/include g++ -I/home/keller/cw/sprout/usr/include -DPJ_AUTOCONF=1 -ggdb3 g++ -DPJ_IS_BIG_ENDIAN=0 -DPJ_IS_LITTLE_ENDIAN=1 g++ -I/home/keller/cw/sprout/usr/include -Wall -O2 -c -o g++ /home/keller/cw/sprout/build/obj/sprout/accumulator.o g++ accumulator.cpp accumulator.cpp: In member function ?void Accumulator::accumulate(long unsigned int)?: accumulator.cpp:56: error: no matching function for call to ?std::__atomic2::__atomic_base<long long unsigned int>::compare_exchange_weak(uint_fast64_t&, long unsigned int&)? /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/atomic_2.h:328: note: candidates are: bool std::__atomic2::__atomic_base<_IntTp>::compare_exchange_weak(_ITp&, _ITp, std::memory_order, std::memory_order) volatile [with _ITp = long long unsigned int] /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/atomic_2.h:333: note: bool std::__atomic2::__atomic_base<_IntTp>::compare_exchange_weak(_ITp&, _ITp, std::memory_order) volatile [with _ITp = long long unsigned int] The code does things like this: while ((sample < lwm) && (!_current._lwm.compare_exchange_weak(lwm, sample))) { // Do nothing. } ...but evidently two arguments are not enough to satisfy the compiler. Any thoughts about a possible cause/cure? Thank you _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
