From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-22 08:51:40
> > So, you've changed -rpath-link to -R. Hmm... I think that's not really
> > right thing. The rpath-link says: when looking for dynamic libraries at
> > link-time, look at this directory. The -R option says: when looking for
> > dynamic library at link-time and *run-time*, look at this directory.
> This is the desired behaviour. I have some dynamic libraries
> whith which I do not want to spoil LD_LIBRARY_PATH. Therefore, I
> use -R. And also for the dynamic libs generated by the Boost
> controlled build, I want to have the correct libs at runtime. I
> see that Boost is manipulating LD_LIBRARY_PATH before a test run
> (with unit-test), but as a user of an application, I do not want
> to do this.
I understand and agree.
> > The reason why the patch is problematic is this. You build an application
> > which uses a library, and install both to /usr/. However, because of the
> > -R option, the application the use the library which is installed in your
> > build tree, not the one in /usr/lib, which is clearly not desirable.
> Correct. For something to be installed, -R is not allowed.
Exactly. V2 has a special feature for that: <hardcode-dll-paths>. If you set
it to true, then paths to dynamic library in your build tree will be
hardcoded into dlls. If you don't use it, they won't be hardcoded. The
problem about your patch is that it essentially make paths always hardcoded.
> > Maybe, the problem is that your's Solaris ld is outdated or something,
> > and you should be using GNU one. I wonder how to force using GNU ld,
> > though.
> IIRC, this is a compile time option of gcc.
Hmm.. then why different linker is used when you invoke collect2 from command
> Additionally, IIRC,
> gcc people advokate the use of the Solaris linker instead of GNU
> Aha, this only holds for older GNU ld. We have exactly GNU ld
> 2.11.2 on our Solaris platform. Maybe we should switch to the
> newer release. I will look into this.
Great. Let me know when you find something.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk