[Signals] Build problem on Linux / ARM with GCC 3.4.4
I'm trying to build Boost.Signals on a Debian-based (Nokia Maemo OS2008 Diablo) system which is using GCC 3.4.4 toolchain (CodeSourcery ARM 2005q3-2). Problem is when linking, I get duplicate symbol boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
(boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
in trackable.o named_slot_map.o Details see below. Any hints? Thanks alot, tgo [sbox-DIABLO_ARMEL: ~/build/boost_1_36_0] > bjam --toolset=gcc --build-dir=/home/oberstet/tmp/boost --with-signals warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 576 targets... ...updating 1 target... gcc.link.dll /home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/libboost_signals-gcc34-mt-1_36.so.1.36.0 /home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/named_slot_map.o:(.bss._ZZN5boost16exception_detail10make_cloneINS0_19error_info_injectorINS_12bad_weak_ptrEEEEEPNS0_10clone_baseERKT_E9bad_alloc[*boost::exception_detail::clone_base* boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
(boost::exception_detail::error_info_injector<boost::bad_weak_ptr> const&)::bad_alloc]+0x0): multiple definition of `boost::exception_detail::clone_base* boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr> (boost::exception_detail::error_info_injector<boost::bad_weak_ptr> const&)::bad_alloc' /home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/trackable.o:(.bss._ZZN5boost16exception_detail10make_cloneINS0_19error_info_injectorINS_12bad_weak_ptrEEEEEPNS0_10clone_baseERKT_E9bad_alloc[boost::exception_detail::clone_base* boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr> (boost::exception_detail::error_info_injector<boost::bad_weak_ptr> const&)::bad_alloc]+0x0): first defined here collect2: ld returned 1 exit status
"g++" -o "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/libboost_signals-gcc34-mt-1_36.so.1.36.0" -Wl,-h -Wl,libboost_signals-gcc34-mt-1_36.so.1.36.0 -shared -Wl,--start-group "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/trackable.o" "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/connection.o" "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/named_slot_map.o" "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/signal_base.o" "/home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/slot.o" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -Wl,--strip-all -pthread ...failed gcc.link.dll /home/oberstet/tmp/boost/boost/bin.v2/libs/signals/build/gcc-3.4.4/release/threading-multi/libboost_signals-gcc34-mt-1_36.so.1.36.0... ...failed updating 1 target... [sbox-DIABLO_ARMEL: ~/build/boost_1_36_0] > g++ --version sbox-arm-linux-g++ (GCC) 3.4.4 (release) (CodeSourcery ARM 2005q3-2) Copyright (C) 2004 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. [sbox-DIABLO_ARMEL: ~/build/boost_1_36_0] >
On Sat, Sep 20, 2008 at 2:20 PM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I'm trying to build Boost.Signals on a Debian-based (Nokia Maemo OS2008 Diablo) system which is using GCC 3.4.4 toolchain (CodeSourcery ARM 2005q3-2).
Problem is when linking, I get duplicate symbol
boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
(boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
I don't have easy access to GCC 3.4.4 but, as far as I can tell from the log, I have no clue why you're getting this error. boost::exception_detail::make_clone is defined in boost/exception/enable_current_exception.hpp, line 123. It is a function template _and_ is marked as inline. Either of these facts should prevent any multiple-definition errors. Right? I will try to take a more careful look later today. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I fixed the problem by patching boost/exception/enable_current_exception.hpp => inlined the templated function make_clone manually into the single call location, which is in class clone_impl. I'll attach the patch, don't know if it makes it through the list. Also: the problem was not at all Boost.Signal related .. some other libs didn't build either. Emil: thx for pointing me to the problematic file .. tgo Emil Dotchevski schrieb:
On Sat, Sep 20, 2008 at 2:20 PM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I'm trying to build Boost.Signals on a Debian-based (Nokia Maemo OS2008 Diablo) system which is using GCC 3.4.4 toolchain (CodeSourcery ARM 2005q3-2).
Problem is when linking, I get duplicate symbol
boost::exception_detail::make_clone<boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
(boost::exception_detail::error_info_injector<boost::bad_weak_ptr>
I don't have easy access to GCC 3.4.4 but, as far as I can tell from the log, I have no clue why you're getting this error.
boost::exception_detail::make_clone is defined in boost/exception/enable_current_exception.hpp, line 123. It is a function template _and_ is marked as inline. Either of these facts should prevent any multiple-definition errors. Right?
ACK. Something weird is happening here ..
I will try to take a more careful look later today.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
______________________ Vicente Juan Botet Escribá ----- Original Message ----- From: "Tobias Oberstein" <tobias.oberstein@gmx.de> To: <boost@lists.boost.org> Cc: <emil@revergestudios.com> Sent: Monday, September 22, 2008 12:40 PM Subject: Re: [boost] [Signals] Build problem on Linux / ARM with GCC 3.4.4
I fixed the problem by patching
boost/exception/enable_current_exception.hpp
=> inlined the templated function make_clone manually into the single call location, which is in class clone_impl.
I'll attach the patch, don't know if it makes it through the list.
Also: the problem was not at all Boost.Signal related .. some other libs didn't build either.
Emil: thx for pointing me to the problematic file ..
Hi, the function is declared firstly without the inline keyword template <class T> clone_base * make_clone( T const & ); and the defined as template <class T> inline clone_base * make_clone( T const & x ) { try { return new exception_clone<T>(x); } catch( std::bad_alloc & ) { static bad_alloc_impl bad_alloc; return &bad_alloc; } catch( ... ) { BOOST_ASSERT(0); return 0; } } } I would try to add inline to the declaration. template <class T> inline clone_base * make_clone( T const & ); Vicente
I would try to add inline to the declaration.
template <class T> inline clone_base * make_clone( T const & );
Yes, I tried this first, but it didn't help. So I patched .. anyway, as far as I can see, make_clone is only used in one place, so no cut'n'paste code dups by "inlining manually".
On Mon, Sep 22, 2008 at 2:04 PM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I would try to add inline to the declaration. template <class T> inline clone_base * make_clone( T const & ); Yes, I tried this first, but it didn't help. So I patched ..
Right, inline isn't part of the function signature and *should* be ignored in declarations.
anyway, as far as I can see, make_clone is only used in one place, so no cut'n'paste code dups by "inlining manually".
Yes it's only one place. But note that this particular function doesn't exist any more, as all of this code has been heavily refactored for the upcoming 1.37 release. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Mon, Sep 22, 2008 at 3:40 AM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I fixed the problem by patching
boost/exception/enable_current_exception.hpp
=> inlined the templated function make_clone manually into the single call location, which is in class clone_impl.
I'll attach the patch, don't know if it makes it through the list.
I would like to investigate if this is compiler-related problem. Looking at the compilers we test Boost on, I don't see GCC 3.4.4, though we do test with 3.4.2, 3.4.3 and 3.4.6. Also, if it isn't too much trouble, could you checkout the latest Trunk from http://svn.boost.org/svn/boost/trunk/ and try your test with it? This code has been heavily refactored after 1.36 was released and trying Trunk will tell us if the problem survived the refactoring. Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil,
On Mon, Sep 22, 2008 at 3:40 AM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I fixed the problem by patching
boost/exception/enable_current_exception.hpp
=> inlined the templated function make_clone manually into the single call location, which is in class clone_impl.
I'll attach the patch, don't know if it makes it through the list.
I would like to investigate if this is compiler-related problem. Looking at the compilers we test Boost on, I don't see GCC 3.4.4, though we do test with 3.4.2, 3.4.3 and 3.4.6.
Also, if it isn't too much trouble, could you checkout the latest Trunk from http://svn.boost.org/svn/boost/trunk/ and try your test with it? This code has been heavily refactored after 1.36 was released and trying Trunk will tell us if the problem survived the refactoring.
I rebuild all Boost libs from trunk. (Side-Q: why does bjam --show-libraries list function_types as a library to be built, when the built does nothing?) Indeed, the "exception related" problem is gone. I still need the 3 patches attached for a full build. First patch is for Boost.Math ... there is no log1pl on this target. The other 2 are for Boost.Filesystem .. again multiple definitions while linking. gcc.link.dll /tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/libboost_filesystem-gcc34-mt-1_37.so.1.37.0 /tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/portability.o:(.bss._ZZNK5boost6system14error_category7messageEiE1s[*boost::system::error_category::message(int) const::s]+0x0): multiple definition of `boost::system::error_category::message(int) const::s' /tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/operations.o:(.bss._ZZNK5boost6system14error_category7messageEiE1s[boost::system::error_category::message(int) const::s]+0x0): first defined here collect2: ld returned 1 exit status "g++" -o "/tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/libboost_filesystem-gcc34-mt-1_37.so.1.37.0" -Wl,-h -Wl,libboost_filesystem-gcc34-mt-1_37.so.1.37.0 -shared -Wl,--start-group "/tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/operations.o" "/tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/path.o" "/tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/portability.o" "/tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/utf8_codecvt_facet.o" "/tmp/boost_trunk/boost/bin.v2/libs/system/build/gcc-3.4.4/release/threading-multi/libboost_system-gcc34-mt-1_37.so.1.37.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -Wl,--strip-all -pthread ...failed gcc.link.dll /tmp/boost_trunk/boost/bin.v2/libs/filesystem/build/gcc-3.4.4/release/threading-multi/libboost_filesystem-gcc34-mt-1_37.so.1.37.0... ...failed updating 1 target...
On Mon, Sep 22, 2008 at 3:57 PM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
Also, if it isn't too much trouble, could you checkout the latest Trunk from http://svn.boost.org/svn/boost/trunk/ and try your test with it? This code has been heavily refactored after 1.36 was released and trying Trunk will tell us if the problem survived the refactoring.
I rebuild all Boost libs from trunk.
(Side-Q: why does bjam --show-libraries list function_types as a library to be built, when the built does nothing?)
Indeed, the "exception related" problem is gone.
Good to hear. Thanks for trying this, I know how frustrating it is.
I still need the 3 patches attached for a full build.
First patch is for Boost.Math ... there is no log1pl on this target.
The other 2 are for Boost.Filesystem .. again multiple definitions while linking.
Perhaps you can host a regular testing site for that platform? I am not sure exactly how to do this but I assume it's a fairly straight-forward installation, and it would let us see the failures throughout development, not after a release is out. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Perhaps you can host a regular testing site for that platform? I am not sure exactly how to do this but I assume it's a fairly straight-forward installation, and it would let us see the failures throughout development, not after a release is out.
I'm not sure what "host a regular testing platform" would mean. What is needed as a dev env for Nokia internet tablets - generally Maemo based devices - is something like this: - Ubuntu 7.10 or 8.04 (other distros might work, but those are Nokia supported) on x86 - Scratchbox / QEmu + CodeSourcery ARM GCC toolchain - Maemo OS roostraps - Maemo SDK You can get all this as a VMware image I think. I'm running under VirtualBox / MacOSX. If boost.org has a developer Ubuntu-x86 server box somewhere, I could setup a build env as some kind of tinderbox. I currently can't host such a beast, since my servers are running on Solaris. On the other hand, setting up such thing is really some work and there are only 2 probs left (currently). tgo
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Sep 22, 2008 at 4:28 PM, Tobias Oberstein <tobias.oberstein@gmx.de> wrote:
I'm not sure what "host a regular testing platform" would mean.
Well it would mean than you can set it up to run on a fixed schedule, and it'll appear with all the other test platforms: http://www.boost.org/development/tests/trunk/developer/summary.html I am sure there's some effort involved in keeping such a thing up and running, plus occasionally developers would bug you with questions regarding failures they see. But if you have vested interest in ensuring Boost runs on your platform, it might be worth the effort. Of course what you're doing now works too.
On the other hand, setting up such thing is really some work and there are only 2 probs left (currently).
That's the problem, "currently". Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (3)
-
Emil Dotchevski -
Tobias Oberstein -
vicente.botet