regex __sync_fetch_and_add_4 issue when compiling to 32 bit Linux
Hi, I seem to have a problem when trying to link C++ code that refers to the boost regex library, when this is done so that it is compiled on a 64 bit Linux system, but for a 32 bit target. I get the following error: libboost_regex.so: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status I wonder what needs to be done to fix this. steps to reproduce: - compile boost for 32 bit, by: ./bjam architecture=x86 address-model=32 --prefix=/path/to/boost install - try to compile & link a very simple sample code (see the end of the mail) g++ -m32 -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx /path/to/boost/lib/libboost_regex.so: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status when compiling the same code for 64 bit, it compiles fine. seeing this thread: http://lists.boost.org/Archives/boost/2008/04/135586.php I also tried the following: g++ -m32 -DBOOST_SP_USE_PTHREADS -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx g++ -m32 -DBOOST_SP_DISABLE_THREADS -L//path/to/boost/lib -I/path/to/boost/include -lboost_regex -o hello hello.cxx but I got the same results :( any help would be appreciated. Akos details: platfrom: Ubuntu 10.10 64 bit compiler: g++ 4.4.4 boost: 1.45.0 the sample code I used is very minimalistic: #include <boost/regex.hpp> int main(void) { boost::regex LF("\\\\n"), CR("\\\\r"), TAB("\\\\t"); return 0; }
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Which gcc version? __sync_fetch_and_add_4 is a gcc intrinsic, and it's never called directly by Boost code (__sync_fetch_and_add is call, gcc expands that to a macro which selects the right version of __sync_fetch_and_add to invoke). This sounds like a problem with your toolchain, not with Boost. You might be neglecting a flag to gcc to properly target 32bit. I could be mistaken about this - the only place in boost that __sync_fetch_and_add is called is in smart_ptr and interprocess, so I'm assuming that your problem is in one of those calls. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk04VzMACgkQ9cB/V3/s9ExVnQCeMvjvPvZ8qVJ6VQ7vjue6ueto upkAnicWX20T8plS3986lfl3bMOKujvb =rSsQ -----END PGP SIGNATURE-----
Bryce,
Which gcc version? __sync_fetch_and_add_4 is a gcc intrinsic, and it's never called directly by Boost code (__sync_fetch_and_add is call, gcc expands that to a macro which selects the right version of __sync_fetch_and_add to invoke).
interesting. I'm using gcc 4.4.4, that comes with Ubuntu 10.10
This sounds like a problem with your toolchain, not with Boost. You might be neglecting a flag to gcc to properly target 32bit.
this is what -m32 does. in fact, boost is compiled for 32 bit using the following flags: -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -march=i386 -pthread -m32 -DBOOST_SP_USE_PTHREADS -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG from which -march=i686 and -m32 are the main points here. I tried to compile the sample code using the exact same flags, but to no avail. sample code that does not refer to libboost_regex compiles & links fine.
I could be mistaken about this - the only place in boost that __sync_fetch_and_add is called is in smart_ptr and interprocess, so I'm assuming that your problem is in one of those calls.
interesting. you're right, a sample code with a simple shared_ptr reference also fails to link with the same error message, where the code is the following: #include <boost/smart_ptr.hpp> int main(void) { boost::shared_ptr<int> p; return 0; } but: this only happens with boost 1.45.0. with boost 1.44.0, it all seems to work fine. interesting... Akos
Ákos Maróy wrote:
Bryce,
but: this only happens with boost 1.45.0. with boost 1.44.0, it all seems to work fine.
interesting...
in tools/build/v2/tools/gcc.jam search for cpu-flags gcc OPTIONS : x86 : i386 : -march=i386 : default ; move the "default" to the line with i686. Works for me, same issue iirc. Christoph
Christoph,
search for cpu-flags gcc OPTIONS : x86 : i386 : -march=i386 : default ; move the "default" to the line with i686.
Works for me, same issue iirc.
works indeed. wonder how this can be achieved without changing this config file. and if it would make sense to have i686 as the default. Akos
Ákos Maróy wrote:
interesting. you're right, a sample code with a simple shared_ptr reference also fails to link with the same error message, where the code is the following: ... but: this only happens with boost 1.45.0. with boost 1.44.0, it all seems to work fine.
interesting...
Indeed. Can you examine boost/smart_ptr/detail/sp_counted_base.hpp and see what's different between 1.44 and 1.45? It should pick the following: #elif defined( __GNUC__ ) && ( defined( __i386__ ) || defined( __x86_64__ ) ) # include <boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp> on either x86 and x64, any idea why it doesn't with -m32? Is __i386__ not defined?
Peter,
Indeed. Can you examine boost/smart_ptr/detail/sp_counted_base.hpp and see what's different between 1.44 and 1.45? It should pick the following:
#elif defined( __GNUC__ ) && ( defined( __i386__ ) || defined( __x86_64__ ) ) # include <boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp>
on either x86 and x64, any idea why it doesn't with -m32? Is __i386__ not defined?
it seems not: $ cat sample.cxx #include <boost/smart_ptr.hpp> #if defined __i386___ #error __i386__ defined #endif int main(void) { boost::shared_ptr<int> p; return 0; } $ g++ -m32 -march=i386 -o sample sample.cxx (goes down fine)
Ákos Maróy wrote:
#if defined __i386___
You have three trailing underscores instead of two here. :-) Could you look at the list of the predefined macros and see what it contains? From memory, you need to do something like touch empty.cpp g++ -m32 -march=i386 -dM -E empty.cpp I've never seen g++ not define __i386__ with -march=i386. Very odd.
Bryce,
Which gcc version? __sync_fetch_and_add_4 is a gcc intrinsic, and it's never called directly by Boost code (__sync_fetch_and_add is call, gcc expands that to a macro which selects the right version of __sync_fetch_and_add to invoke).
This sounds like a problem with your toolchain, not with Boost. You might be neglecting a flag to gcc to properly target 32bit.
I could be mistaken about this - the only place in boost that __sync_fetch_and_add is called is in smart_ptr and interprocess, so I'm assuming that your problem is in one of those calls.
actually, with boost 1.44.0, a simple code sample that only referst so smart_ptr.hpp compiles & links fine. but a sample that refers to boost::regex, it will fail with the same __sync_fetch_and_add_4 issue. so, it seems in boost 1.44.0, this is indeed a regex related problem. Akos
participants (2)
-
Bryce Lelbach -
Christoph Duelli -
Peter Dimov -
Ákos Maróy