[Signals-1.30.0] Linking problems
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got problems in linking against the signals-library. I built the library defining <define>BOOST_SIGNALS_NAMESPACE=boost_signals and running bjam -sTOOLS=gcc-stlport -sBUILD=release Everythinig seemed to work fine, but when I now try to link against the shared library (see attached file), I get the following undefined references: undefined reference to `boost::boost_signals::detail::signal_base_impl::connect_slot(boost::any const&, boost::any const&, _STL::vector<boost::boost_signals::trackable const*, _STL::allocator<boost::boost_signals::trackable const*> > const&)' and undefined reference to `boost::boost_signals::detail::signal_base_impl::signal_base_impl[in-charge](boost::function2<bool, boost::any, boost::any, _STL::allocator<boost::function_base> > const&)' I'm using gcc-3.2.2 and STLport-4.5.3. May it be the case that something with the STL-namespace (std) went wrong? Thanks for any help, Michael - -- Dipl.-Ing. Michael Kettner, Wissenschaftlicher Mitarbeiter Institut für Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover Appelstr. 9A # Tel: ++49/(0)511/762-4273 D-30167 Hannover # Fax: ++49/(0)511/762-3001 http://www.ive.uni-hannover.de # kettner@ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+iIILkCdGnb0kVFMRAtewAJ9+MNdRW7hs4vHHbmnuashsi22d8gCaAm8W N8FnJqbRHiqU3S0EKDixD0U= =qEMK -----END PGP SIGNATURE----- [Non-text portions of this message have been removed]
On Monday 31 March 2003 12:59 pm, Michael Kettner wrote:
Hi,
I've got problems in linking against the signals-library. I built the library defining <define>BOOST SIGNALS NAMESPACE=boost signals and running bjam -sTOOLS=gcc-stlport -sBUILD=release Everythinig seemed to work fine, but when I now try to link against the shared library (see attached file), I get the following undefined references:
Do the testcases run properly? e.g., use the same bjam command line in libs/signals/test and check if there are any failures.
I'm using gcc-3.2.2 and STLport-4.5.3.
May it be the case that something with the STL-namespace (std) went wrong?
If the Signals testcases are running properly, I would guess that the gcc-stlport toolset is using different STLport options than you are using in your own program, and its affecting the name of the STLport namespace. One way you can check this would be to use "nm libboost_signals.a|c++filt" to see what STLport namespace the Boost.Signals classes refer to. Doug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Doug,
Do the testcases run properly? e.g., use the same bjam command line in libs/signals/test and check if there are any failures.
I tried the testcases and erverything ran properly.
If the Signals testcases are running properly, I would guess that the gcc-stlport toolset is using different STLport options than you are using in your own program, and its affecting the name of the STLport namespace. One way you can check this would be to use "nm libboost_signals.a|c++filt" to see what STLport namespace the Boost.Signals classes refer to.
That was the point: the boost-signals library used the namespace "std" (and not "_STL" as my program), because STLPORT_ROOT was not set. Instead I set STLPORT_PATH, as required under Windows. Changing STLPORT_PATH to STLPORT_ROOT and re-builduing boost-signals fixed all undefined references. Thanks for your help! This brings me to another point: I think it is extremely inconvenient to set STLPORT_ROOT under Linux and STLPORT_PATH under Windows as it is a source for errors like my one. Why couldn't you change boost-signals, so that STLPORT_ROOT is used on all platforms (like BOOST_ROOT, for example)? Michael - -- Dipl.-Ing. Michael Kettner, Wissenschaftlicher Mitarbeiter Institut für Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover Appelstr. 9A # Tel: ++49/(0)511/762-4273 D-30167 Hannover # Fax: ++49/(0)511/762-3001 http://www.ive.uni-hannover.de # kettner@ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+iaC/kCdGnb0kVFMRAlN9AJ9SSxgYmbxXL5YvI96x7BBF+xz7zQCfQFlp zY7osPa3DGFaxXhf1i5aS84= =Jb9S -----END PGP SIGNATURE-----
On Tuesday 01 April 2003 09:22 am, Michael Kettner wrote:
This brings me to another point: I think it is extremely inconvenient to set STLPORT ROOT under Linux and STLPORT PATH under Windows as it is a source for errors like my one. Why couldn't you change boost-signals, so that STLPORT ROOT is used on all platforms (like BOOST ROOT, for example)?
Michael
I see (from stlport.jam) that both STLPORT_PATH and STLPORT_ROOT are supported on the GCC side, but STLPORT_ROOT is marked deprecated. Looks like you can use STLPORT_PATH in the same way on Linux and Windows: path ?= $(STLPORT_$(version)_PATH) ; path ?= $(STLPORT_PATH)$(SLASH)STLport-$(version) ; path ?= $(STLPORT_ROOT) ; #<< For backward compatability. This is more of a Boost.Jam/Boost.Build question, because the Signals library itself doesn't know the difference between STLport on Windows or on Linux per se. They generally prefer that Jam-related questions go to jamboost@yahoogroups.com but usually answer questions here as well. Doug
On Mon, Mar 31, 2003 at 07:59:39PM +0200, Michael Kettner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I've got problems in linking against the signals-library. I built the library defining <define>BOOST_SIGNALS_NAMESPACE=boost_signals and running bjam -sTOOLS=gcc-stlport -sBUILD=release Everythinig seemed to work fine, but when I now try to link against the shared library (see attached file), I get the following undefined references:
undefined reference to `boost::boost_signals::detail::signal_base_impl::connect_slot(boost::any const&, boost::any const&, _STL::vector<boost::boost_signals::trackable const*, _STL::allocator<boost::boost_signals::trackable const*> > const&)'
This error suggests that you did not link correctly with stlport. The "-lstlport" option must appear on the link line, AFTER any of the -lboost... options.
I'm using gcc-3.2.2 and STLport-4.5.3.
BTW: I was under the impression that GCC 3.2 had a sufficiently-developed standard library, and does not need to use STLport. Is that not the case? -S
On Monday 31 March 2003 02:31 pm, Steve M. Robbins wrote:
I'm using gcc-3.2.2 and STLport-4.5.3.
BTW: I was under the impression that GCC 3.2 had a sufficiently-developed standard library, and does not need to use STLport. Is that not the case?
STLport has a wonderful debug mode that helps find errors in the use of STL (e.g., dereferencing past-the-end iterators and such). I also know that some users prefer to use STLport because it is a common library platform and they can be sure their code will port to other compilers/architectures (that may otherwise have different standard library implementations). Doug
participants (3)
-
Douglas Gregor -
Michael Kettner -
Steve M. Robbins