RPATH/RUNPATH issue, equivalent to -headerpad on OSX

Alexander Neundorf neundorf@kde.org
Fri Jan 4 14:05:00 GMT 2008

On Thursday 03 January 2008, Michael Hennebry wrote:
> On Thu, 3 Jan 2008, Jakub Jelinek wrote:
> > On Thu, Jan 03, 2008 at 01:54:04PM +0100, Alexander Neundorf wrote:
> > > 1) build the executables with RPATH to the build directory, and when
> > > installing link them again with the modified RPATH for the install
> > > location
> > >
> > > This works correctly and convenient, but it takes a lot of time (really
> > > a lot for big projects).
> This surprises me.
> I'd have thought that link time would
> be small compared to compile time.

If you have some compiler cluster, you can distribute the compilation over the 
network, but the linking still has to be done locally.
But what I am talking about is the time it takes to change the RPATH/RUNPATH 
when installing a binary, which is required if you need different RPATHs in 
the build tree and in the install tree. This means the linking happens for 
the build tree when you build the project, and once *again* for the install 
tree to get binaries with the RPATH for the install tree.

> > BTW, on Linux, you generally want to avoid RPATH/RUNPATH for the
> > installed binaries/libraries, because it is expensive at runtime, ld.so
> > needs to search all the paths in RPATH/RUNPATH lists, compared to
> > libraries which are just looked up from ld.so.cache.  Adding
> > /etc/ld.so.conf.d/*.conf snippets for the extra dirs (if you need any) is
> > preferrable, provided there are no SONAME clashes.
> That suggests a solution:
> Use RPATH in the build tree.
> Shrink it to nothing in the installed version.

I can't decide which RPATH setup developers/users want for their projects.


More information about the Binutils mailing list