Boost logo

Boost :

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-12-09 08:14:10

On Thu, Dec 09, 2004 at 09:54:08AM +0000, Oliver Kullmann wrote:

> > > The linking warning:
> > >
> > > g++ -c -o TimeHandling_Applications_DaysDifference.o TimeHandling_Applications_DaysDifference.cpp
> > > g++ -o TimeHandling_Applications_DaysDifference TimeHandling_Applications_DaysDifference.o -lboost_date_time-gcc
> > > /usr/bin/ld: warning:, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../, may conflict with
> >
> > The warning clearly says that requires
> > - that means you compiled Boost with GCC 3.3
> >
> not necessarily --- it only means that when building,
> it was *linked* to, and that exactly seems to be the problem (see below).

True - my mistake, sorry.

> > Try running "ldd /usr/local/lib/" and see which
> > version of libstdc++ it requires (it will say
> >
> > ldd /usr/local/lib/
> => /usr/lib/ (0x4002e000)
> => /lib/i686/ (0x400ee000)
> => /usr/local/lib/ (0x40111000)
> => /lib/i686/ (0x4011b000)
> /lib/ => /lib/ (0x80000000)
> Here you see that it links to in */usr/lib* !!
> > Did you build Boost before upgrading your compiler?
> no;

Oh :-)

> > If so, when you
> > re-ran "bjam install" it won't have rebuilt the libraries, it will just
> > have copied the libraries you had already built (with GCC 3.3) into
> > /usr/local/lib. If this is the case, you should delete the compiled
> > binaries and rebuild.
> >
> I always just delete the old Boost directories.
> To be safe, again(!) I've build gcc 3.4.3 and, then, after this,
> Boost, and (of course) nothing changes.
> The problem is as follows:
> > ls -l /usr/lib/
> lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/ ->
> > ls -l /usr/local/lib/
> lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/ ->
> You see that the gcc installation put libstdc++ into /usr/local/lib, the default place.
> But Boost linked to /usr/lib/, the old version.
> So it seems to me that the Boost build process is erroneous:
> gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib
> (to the best of my knowledge).

You can see what directories are used by adding "-v" to the GCC command
line. I think you're right that GCC will look in the directory it was
installed to before any others, but any directories added with "-L" will
come first. If Boost is passing -L/usr/lib then it would cause your
problem - I'd be surprised if it is though.

> This is what one should also expect from the Boost build process, however, somehow it overrides the
> default and links (first) to /usr/lib.
> I'm using the only version of bjam parameters mentioned in the build instructions:
> bjam "-sTOOLS=gcc" install

I think you could force the right directory to be the first like so:

bjam "-sTOOLS=gcc" "-sGXX=g++ -L/usr/local/lib" install

That would certainly be easier than hiding all the libs in /usr/lib

You might also be able to use -sGCC_STDLIB_DIRECTORY=/usr/local/lib
but AFAIK that should be found OK if /usr/local/bin/g++ is being used.
Similarly, GCC_ROOT_DIRECTORY should be set correctly.

> Obviously, to temporarily solve the problem, I could hide the lib's in /usr/lib,
> but there seems to me a problem with the Boost build process which should better
> be addressed.

Yes, if Boost is forcing /usr/lib into the search path that's a problem.

But you might have a problem with your GCC installation(s) - I build
Boost using experimental versions of GCC installed in ~/gcc/4.x/lib all
the time and never get clashes with /usr/lib/libstdc++.*


"We are all in the gutter, but some of us are looking at the stars."
	- Oscar Wilde

Boost list run by bdawes at, gregod at, cpdaniel at, john at