Re: [Boost-users] [SOLVED] Undefined reference to boost_serialization even though it is specified with -lboost_serialization

Subject: Re: [Boost-users] [SOLVED] Undefined reference to boost_serialization even though it is specified with -lboost_serialization
From: Cedric Laczny (cedric.laczny_at_[hidden])
Date: 2011-02-24 08:03:17

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/whatever/header.hpp>"), as they are searched 
_before_ the standard system include directories (s. 
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Preprocessor-
Options.html#Preprocessor-Options -> "-I dir")
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

Best,

Cedric