Undefined reference to boost_serialization even though it is specified with -lboost_serialization
Sorry, my bad. Hit "Send" before being finished...
So let's start again... I apologize.
Hi,
I have a program that uses serialization-functionality for some of the self-
defined classes.
I specify "-lboost_serialization" with the g++ and it works fine on my local
machine.
However, when I want to compile it on a remote machine, it fails. The remote
machine is lacking >=boost-1.42 which is needed. Therefore I built (no
install) boost-1.45 remotely (under /local/cedric/boost_1_45_0) and at least
the configure-script (generated using autotools) seems to detect all the
necessary libraries and headers (provided I specify them in the environment
variables), on my local machine aswell as on the remote machine.
Now the problem is, that I don't find the reason why it fails to compile my
program remotely...
Any ideas?
Here's the command used for linking:
/bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 -
lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test-
main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
and an excerpt of the error (taken from the end):
...
MicroCosmParser.cpp:
(.text._ZN5boost13serialization6detail17singleton_wrapperINS0_25extended_type_info_typeidI15MicroCosmParserEEED0Ev[boost::serialization::detail::singleton_wrapper ::~singleton_wrapper()]+0x17): undefined reference to
`boost::serialization::detail::extended_type_info_typeid_0::type_unregister()'
MicroCosmParser.cpp:
(.text._ZN5boost13serialization6detail17singleton_wrapperINS0_25extended_type_info_typeidI15MicroCosmParserEEED0Ev[boost::serialization::detail::singleton_wrapper collect2: ld returned 1 exit status Best,
Cedric
Here's the command used for linking: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 - lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test- main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
Hi Cedric, I did't understand exactly what you meant with 'compiling remotely' (cross-compiling?), but if I don't mistake, you should specify first -L, then -l in command line. If changing order does not help, use binutils to find where the symbols are located. Pay attention as well to linker messages like 'skipping ... due to incompatible format' or something alike if you cross-compile. -- Slava
Hi Slava, On Thursday, 24. February 2011 11:32:12 Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:
Here's the command used for linking: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 - lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test- main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
Hi Cedric,
I did't understand exactly what you meant with 'compiling remotely' (cross-compiling?),
I meant "compiling on a remote machine" by that. Sorry for not being more clear about this. I have only basic user privileges on that machine, so I had to resort to building (not installing) boost-1.45 locally.
but if I don't mistake, you should specify first -L, then -l in command line. If changing order does not help, use binutils to find where the symbols are located. Pay attention as well to linker messages like 'skipping ... due to incompatible format' or something alike if you cross-compile.
-- Slava
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I meant "compiling on a remote machine" by that. Sorry for not being more clear about this. I have only basic user privileges on that machine, so I had to resort to building (not installing) boost-1.45 locally.
If you sure, the library compiled on one machine will fit in onto another, then fine... Pay attention to linker warning. Try link stage with --verbose to make sure boost library was found and used. Check with objdump/readelf which (not found) symbols are undefined in your object files and whethere they are defined in the boost library binaries. If they match, well, pay attention to linker messages again ;) // Btw you don't need any special privileges to just build boost, so you may spare the headache and build all on target machine -- Slava
On Thursday, 24. February 2011 12:46:37 Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:
I meant "compiling on a remote machine" by that. Sorry for not being more clear about this. I have only basic user privileges on that machine, so I had to resort to building (not installing) boost-1.45 locally.
If you sure, the library compiled on one machine will fit in onto another, then fine... Pay attention to linker warning. Try link stage with --verbose to make sure boost library was found and used. Check with objdump/readelf which (not found) symbols are undefined in your object files and whethere they are defined in the boost library binaries. If they match, well, pay attention to linker messages again ;)
Thank you for the suggestions. Although they didn't help me out this time, I really appreciate your fairly new ideas ;)
// Btw you don't need any special privileges to just build boost, so you may spare the headache and build all on target machine
-- Slava
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Best, Cedric
On 24 Feb 2011, at 10:14, Cedric Laczny wrote:
Sorry, my bad. Hit "Send" before being finished...
So let's start again... I apologize.
Hi,
I have a program that uses serialization-functionality for some of the self- defined classes. I specify "-lboost_serialization" with the g++ and it works fine on my local machine. However, when I want to compile it on a remote machine, it fails. The remote machine is lacking >=boost-1.42 which is needed. Therefore I built (no install) boost-1.45 remotely (under /local/cedric/boost_1_45_0) and at least the configure-script (generated using autotools) seems to detect all the necessary libraries and headers (provided I specify them in the environment variables), on my local machine aswell as on the remote machine. Now the problem is, that I don't find the reason why it fails to compile my program remotely... Any ideas?
Here's the command used for linking: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 - lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test- main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
This might not be your problem, but I have seen issues like this when the included headers and linked libraries are not in sync with each other. Make sure you are both picking up the right headers, and the right library files.
On Thursday, 24. February 2011 12:23:29 Christopher Jefferson wrote:
On 24 Feb 2011, at 10:14, Cedric Laczny wrote:
Sorry, my bad. Hit "Send" before being finished...
So let's start again... I apologize.
Hi,
I have a program that uses serialization-functionality for some of the self- defined classes. I specify "-lboost_serialization" with the g++ and it works fine on my local machine. However, when I want to compile it on a remote machine, it fails. The remote machine is lacking >=boost-1.42 which is needed. Therefore I built (no install) boost-1.45 remotely (under /local/cedric/boost_1_45_0) and at least the configure-script (generated using autotools) seems to detect all the necessary libraries and headers (provided I specify them in the environment variables), on my local machine aswell as on the remote machine. Now the problem is, that I don't find the reason why it fails to compile my program remotely... Any ideas?
Here's the command used for linking: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 - lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test- main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
This might not be your problem, but I have seen issues like this when the included headers and linked libraries are not in sync with each other. Make sure you are both picking up the right headers, and the right library files.
I know this should be rather done in the opposite direction (correct configuration at the beigninning), but can you tell me how I can find out, which versions were actually used? I know about "ldd" which AFAIK only works for executable binaries. Your point sounds reasonable to me in my scenario and this might help me track down the issue... Thank you.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thursday, 24. February 2011 12:23:29 Christopher Jefferson wrote:
On 24 Feb 2011, at 10:14, Cedric Laczny wrote:
Sorry, my bad. Hit "Send" before being finished...
So let's start again... I apologize.
Hi,
I have a program that uses serialization-functionality for some of the self- defined classes. I specify "-lboost_serialization" with the g++ and it works fine on my local machine. However, when I want to compile it on a remote machine, it fails. The remote machine is lacking >=boost-1.42 which is needed. Therefore I built (no install) boost-1.45 remotely (under /local/cedric/boost_1_45_0) and at least the configure-script (generated using autotools) seems to detect all the necessary libraries and headers (provided I specify them in the environment variables), on my local machine aswell as on the remote machine. Now the problem is, that I don't find the reason why it fails to compile my program remotely... Any ideas?
Here's the command used for linking: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wno-deprecated -g -O2 - lboost_serialization -L/local/cedric/boost_1_45_0/stage/lib -o test test- main.o ../includes/Parser/libparser.a -lgsl -lgslcblas -lm
This might not be your problem, but I have seen issues like this when the included headers and linked libraries are not in sync with each other. Make sure you are both picking up the right headers, and the right library files.
In fact this _was_ my problem. Thank you for pointing this out.
So in order to pick the right headers (matching the libraries), I include the
appropriate CPPFLAGS details, in my case CPPFLAGS="$CPPFLAGS -
I/local/cedric/boost_1_45_0".
Thus, my compile line looks like this:
g++ -DHAVE_CONFIG_H -Wno-deprecated -I../includes/ -
I/local/cedric/boost_1_45_0 -Wall -pedantic -g -O2 -MT test-main.o -MD -MP -
MF .deps/test-main.Tpo -c -o test-main.o `test -f 'main.cpp' || echo
'./'`main.cpp
and finally for the linking:
g++ -g -O2 -o test test-main.o -L/local/cedric/boost_1_45_0/stage/lib
../includes/Parser/libparser.a -lboost_serialization -lgsl -lgslcblas -lm
It should be noted, that I use this CPPFLAGS-variable already when compiling
the objects for my custom libparser.a-library to make sure everything is in
sync.
In case someone wonders about the rather ugly command-lines, these are
automatically generated by automake (part of GNU autotools).
In order to respect the location of the boost-build, I use the boost.m4 macros
for autoconf which define BOOST_CPPFLAGS, if one points the configure-script
(using --with-boost) to the custom boost-build (like in my case
/local/cedric/boost_1_45_0).
So if the user wants/needs a different boost-build than the global-
installation, the "-I$(BOOST_CPPFLAGS)" guarantees that g++ will first look
there for the included headers. No adjustment in the source-files is needed
(keep your "#include
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Best, Cedric
participants (3)
-
Cedric Laczny -
Christopher Jefferson -
Viatcheslav.Sysoltsev＠h-d-gmbh.de