undefined reference to `__sync_fetch_and_add_4'
Hi, I built boost 1.38 as so: bjam architecture=x86 address-model=32 --stagedir=stage32 --with-filesystem --with-thread --with-signals --with-serialization --with-system --with-program_options --with-date_time stage Copied the files over to /usr/local/lib32: sudo cp stage32/lib/* /usr/local/lib32/ Compiled object files, eg: g++ -m32 -c -g -D_LINUX -I. -I/opt/sts_vendor/onix-eurex/include -I/usr/local/include/boost-1_38 -MMD -MP -MF build/Debug/GNU-Linux-x86/reference/ReferenceData.o.d -o build/Debug/GNU-Linux-x86/reference/ReferenceData.o reference/ReferenceData.cpp Then linking does not work: g++ -m32 -o dist/Debug/GNU-Linux-x86/spreadx build/Debug/GNU-Linux-x86/multicast/MulticastChannel.o build/Debug/GNU-Linux-x86/reference/ReferenceData.o build/Debug/GNU-Linux-x86/reference/Strategy.o build/Debug/GNU-Linux-x86/executor/MessageExecutor.o build/Debug/GNU-Linux-x86/multicast/MulticastSelector.o build/Debug/GNU-Linux-x86/fast/FIXStreamSubscriber.o build/Debug/GNU-Linux-x86/reference/Product.o build/Debug/GNU-Linux-x86/spreadx.o build/Debug/GNU-Linux-x86/fast/FIXMessage.o build/Debug/GNU-Linux-x86/multicast/Message.o build/Debug/GNU-Linux-x86/fast/FastDecoder.o build/Debug/GNU-Linux-x86/reference/Outright.o -L/opt/sts_vendor/onix-eurex/lib -L/usr/tibco/tibrv/lib -L/usr/local/lib32 -lffCppFixEngine -lACE -lcrypto -lboost_serialization-gcc43-mt -lboost_system-gcc43-mt -lboost_thread-gcc43-mt /usr/local/lib32/libboost_serialization-gcc43-mt.so: undefined reference to `__sync_fetch_and_add_4' I've tried #define BOOST_SP_USE_PTHREADS in user.hpp, I've tried -march=i486, but neither works. What gives? My platform details: birju@xx:~$ g++ --version g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2 Copyright (C) 2008 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. birju@xx:~$ uname -a Linux xx 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux birju@xx:~$ Cheers, Birju Schneider Trading 4th Floor, 25 Copthall Avenue London EC2R 7BP -------------------------------------------------------- Message from: Birju.Prajapati@schneidertrading.com Message to: boost-users@lists.boost.org Attached files: 0 This e-mail and any files transmitted with it are confidential, may be legally privileged, and are for the sole use of the intended recipient. Copyright in this e-mail and any accompanying document created by us is owned by us. If you are not the intended recipient of this e-mail or any part of it please telephone our IT Department at the number shown above or by e-mail at info@schneidertrading.com. You should not use or disclose to any other person the contents of this e-mail or its attachments (if any), nor take copies. This e-mail is not a representation or warranty and is not intended nor should it be taken to create any legal relations, contractual or otherwise. Schneider Trading Associates Ltd (Registration No. 3692131) is incorporated in England and Wales and the registered office is at 25 Copthall Avenue, London EC2R 7BP. The company is authorised and regulated by the Financial Services Authority
Birju Prajapati:
g++ -m32 [...]
/usr/local/lib32/libboost_serialization-gcc43-mt.so: undefined reference to `__sync_fetch_and_add_4'
This is weird. __sync_fetch_and_add is used by shared_ptr and atomic_count, but in both places, the earlier #elif defined( __GNUC__ ) && ( defined( __i386__ ) || defined( __x86_64__ ) ) takes precedence, and I have verified that g++ -m32 does indeed define __i386__. This could be caused by an issue we've identified recently of libstdc++ standard headers using __sync_fetch_and_add as part of their reference counted implementation of std::string and std::locale.
Peter Dimov wrote:
Birju Prajapati:
g++ -m32 [...]
/usr/local/lib32/libboost_serialization-gcc43-mt.so: undefined reference to `__sync_fetch_and_add_4'
This is weird. __sync_fetch_and_add is used by shared_ptr and atomic_count, but in both places, the earlier
#elif defined( __GNUC__ ) && ( defined( __i386__ ) || defined( __x86_64__ ) )
takes precedence, and I have verified that g++ -m32 does indeed define __i386__.
This could be caused by an issue we've identified recently of libstdc++ standard headers using __sync_fetch_and_add as part of their reference counted implementation of std::string and std::locale.
Or probably by the fact that -m32 was not, in fact, passed to compiler when building boost. - Volodya
Vladimir Prus:
Peter Dimov wrote:
...
This could be caused by an issue we've identified recently of libstdc++ standard headers using __sync_fetch_and_add as part of their reference counted implementation of std::string and std::locale.
Or probably by the fact that -m32 was not, in fact, passed to compiler when building boost.
The original post stated:
I built boost 1.38 as so:
bjam architecture=x86 address-model=32 --stagedir=stage32 --with-filesystem --with-thread --with-signals --with-serialization --with-system --with-program_options --with-date_time stage
so I assumed that address-model=32 does pass -m32 to g++.
Peter Dimov wrote:
Vladimir Prus:
Peter Dimov wrote:
...
This could be caused by an issue we've identified recently of libstdc++ standard headers using __sync_fetch_and_add as part of their reference counted implementation of std::string and std::locale.
Or probably by the fact that -m32 was not, in fact, passed to compiler when building boost.
The original post stated:
I built boost 1.38 as so:
bjam architecture=x86 address-model=32 --stagedir=stage32 --with-filesystem --with-thread --with-signals --with-serialization --with-system --with-program_options --with-date_time stage
so I assumed that address-model=32 does pass -m32 to g++.
It should, but I don't have any other theory why -march=i686 might have changed anything. Maybe, an obsolete Boost.Build version was installed on machine -- and does not ever pass -m32 explicitly. bjam -n -a <other option> will tell for sure. - Volodya
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 24 April 2009 18:30 To: boost-users@lists.boost.org Subject: Re: [Boost-users] undefined reference to `__sync_fetch_and_add_4'
Peter Dimov wrote:
Vladimir Prus:
Peter Dimov wrote:
...
This could be caused by an issue we've identified recently of libstdc++ standard headers using __sync_fetch_and_add as part of their reference counted implementation of std::string and std::locale.
Or probably by the fact that -m32 was not, in fact, passed to compiler when building boost.
The original post stated:
I built boost 1.38 as so:
bjam architecture=x86 address-model=32 --stagedir=stage32 --with-filesystem --with-thread --with-signals --with-serialization --with-system --with-program_options --with-date_time stage
so I assumed that address-model=32 does pass -m32 to g++.
It should, but I don't have any other theory why -march=i686 might have changed anything. Maybe, an obsolete Boost.Build version was installed on machine -- and does not ever pass -m32 explicitly.
bjam -n -a <other option>
It was a bit of a long shot, I stumbled across these clues: http://archives.devshed.com/forums/development-94/new-undefined-referenc e-to-sync-fetch-and-add-4t-1971252.html http://www.mail-archive.com/users@lists.strongswan.org/msg00050.html http://markmail.org/message/dnxjspjzyrbwzqhm And looked into gcc.jam, which defaults to i386. So I realised that instead of passing -march=iN86 (where i> 3) to linking my app, I should try to pass it to bjam when building boost, namely 'instruction-set' By the way, my bjam version: birju@xx:~/Downloads/boost_1_38_0$ bjam --help Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 ....blah....
will tell for sure.
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Schneider Trading 4th Floor, 25 Copthall Avenue London EC2R 7BP -------------------------------------------------------- Message from: Birju.Prajapati@schneidertrading.com Message to: boost-users@lists.boost.org Attached files: 0 This e-mail and any files transmitted with it are confidential, may be legally privileged, and are for the sole use of the intended recipient. Copyright in this e-mail and any accompanying document created by us is owned by us. If you are not the intended recipient of this e-mail or any part of it please telephone our IT Department at the number shown above or by e-mail at info@schneidertrading.com. You should not use or disclose to any other person the contents of this e-mail or its attachments (if any), nor take copies. This e-mail is not a representation or warranty and is not intended nor should it be taken to create any legal relations, contractual or otherwise. Schneider Trading Associates Ltd (Registration No. 3692131) is incorporated in England and Wales and the registered office is at 25 Copthall Avenue, London EC2R 7BP. The company is authorised and regulated by the Financial Services Authority
It was a bit of a long shot, I stumbled across these clues:
http://archives.devshed.com/forums/development-94/new-undefined-referenc e-to-
sync-fetch-and-add-4t-1971252.html http://www.mail-archive.com/users@lists.strongswan.org/msg00050.html http://markmail.org/message/dnxjspjzyrbwzqhm
Here we go: http://stackoverflow.com/questions/130740/link-error-when-compiling-gcc- atomic-operation-in-32-bit-mode So with a x86_64 processor, when compiling a 32 bit boost, bjam shouldn't default to i386, but something 'better'.
And looked into gcc.jam, which defaults to i386. So I realised that
passing -march=iN86 (where i> 3) to linking my app, I should try to
instead of pass it to
bjam when building boost, namely 'instruction-set'
By the way, my bjam version: birju@xx:~/Downloads/boost_1_38_0$ bjam --help Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 ....blah....
will tell for sure.
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Schneider Trading 4th Floor, 25 Copthall Avenue London EC2R 7BP -------------------------------------------------------- Message from: Birju.Prajapati@schneidertrading.com Message to: Birju.Prajapati@schneidertrading.com, boost-users@lists.boost.org Attached files: 0 This e-mail and any files transmitted with it are confidential, may be legally privileged, and are for the sole use of the intended recipient. Copyright in this e-mail and any accompanying document created by us is owned by us. If you are not the intended recipient of this e-mail or any part of it please telephone our IT Department at the number shown above or by e-mail at info@schneidertrading.com. You should not use or disclose to any other person the contents of this e-mail or its attachments (if any), nor take copies. This e-mail is not a representation or warranty and is not intended nor should it be taken to create any legal relations, contractual or otherwise. Schneider Trading Associates Ltd (Registration No. 3692131) is incorporated in England and Wales and the registered office is at 25 Copthall Avenue, London EC2R 7BP. The company is authorised and regulated by the Financial Services Authority
participants (3)
-
Birju Prajapati -
Peter Dimov -
Vladimir Prus