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: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
The warning clearly says that libboost_date_time-gcc.so requires libstdc++.so.5 - that means you compiled Boost with GCC 3.3
not necessarily --- it only means that when building libboost_date_time-gcc.so, it was *linked* to libstdc++.so.5, and that exactly seems to be the problem (see below).
True - my mistake, sorry.
Try running "ldd /usr/local/lib/libboost_date_time-gcc.so" and see which version of libstdc++ it requires (it will say libstdc++.so.5)
ldd /usr/local/lib/libboost_date_time-gcc.so libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002e000) libm.so.6 => /lib/i686/libm.so.6 (0x400ee000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x40111000) libc.so.6 => /lib/i686/libc.so.6 (0x4011b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Here you see that it links to libstdc++.so.5 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/libstdc++.so lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/libstdc++.so -> libstdc++.so.5.0.5 ls -l /usr/local/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/libstdc++.so -> libstdc++.so.6.0.3
You see that the gcc installation put libstdc++ into /usr/local/lib, the default place. But Boost linked to /usr/lib/libstdc++.so, 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++.* jon -- "We are all in the gutter, but some of us are looking at the stars." - Oscar Wilde