Vladimir Prus writes:
The "/usr/local/lib" is not default place for anything, AFAICT. All system-wide libraries installed in a regular way should go to /usr/lib.
/usr/local/lib actually _is_ the default place for gcc to put stuff if you just download a tarball, untar and "configure/make/make install", so it's not surprising to see this. It looks like the machine came with a "built in" gcc where everything was in /usr/lib/, then somebody upgraded gcc by just installing overtop from a build from a tarball. I'm curious: has the OP been able to do anything else with equally complicated linking, with this compiler installation? (build a shared object that links against libstdc++, then link against this shared object)
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).
If you're using gcc installed to /usr/local, then maybe you have to that the gcc tooset about this with:
bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/usr/local
I'm not 100% sure what the GCC_ROOT_DIRECTORY is for, but seems to me that if the gcc in question had been built with --enable-version-specific-runtime-libs specified, the problem could just go away... hope that helps, -t