Re: [boost] Re: program_options: undefined behaviour seems unavoidable

From: troy d. straszheim (troy_at_[hidden])
Date: 2004-12-09 06:24:52

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