[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removing rpath from libtool

From: Ralf Wildenhues
Subject: Re: removing rpath from libtool
Date: Wed, 24 Oct 2007 21:44:51 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Wintaki,

* Wintaki Hagabashi wrote on Tue, Oct 23, 2007 at 08:21:57PM CEST:
> We are using libtool 1.5.6.

The current release is 1.5.24.  Not that it has much to do with your
issue, but otherwise there are many changes since.  Please update.

>  How can we disable libtools use of rpath?

One possibility is to install all libraries in a directory that the
runtime linker will search by default, such as /usr/lib[1].  Then
libtool will not add run paths to libraries or executables, unless they
also link against other libraries installed in unusual locations.

The use of run paths ensures that the installed programs can be
executed.  I understand that they are not relocatable that way.
I also understand that, since you are using Linux and Solaris only,
there are better possibilities wrt. relocatability on these two systems.
But they are not portable to other systems.

For portable relocatable packages you can look into the gnulib modules
named relocatable-{lib,prog} and some more.

> It is causing us trouble.  The problem is we are building libraries
> that are then later shipped and installed on other systems.  We can
> not control where they get installed since it is a customer's system. 
> Now what happened was the rpath embedded in our .so's happened to
> partially match a broken NFS mount on a customers site.  This then
> caused the system to hang for a long time when trying to start the
> apps because the system tried to look in the rpath that was not valid. 

Really this is a problem with the customer's system setup.

> I really don't see the need for rpath at all, maybe it makes sense on
> other systems, but we are on Linux & Solaris. 

Well, if I install a shared library in /opt/foo-package/lib and link a
program against it without an rpath, how will the runtime linker find
it otherwise?  Setting LD_LIBRARY_PATH is very bad, for many reasons.

Moreover, if I want to execute an uninstalled program that links against
the just-build (uninstalled) libraries, then not using rpaths at all
makes this very error-prone, or just breaks it.  Libtool takes care of
this, and it's typically needed for "make check", for test programs and
so on.

> Is there a way to disable this?  I googled a bit but most of the
> discussions seem to be from around 1999 on the debian mailing list. 

Well, likely because it is not a good idea to disable this globally.

Besides the two possibilities mentioned above (install in searched
directories, use the gnulib modules), there is a very hacky way to get
libtool not to add rpaths at all.  After configure, in the generated
libtool script, set hardcode_libdir_flag_spec to " ", once near the
beginning and several times at the end of the script.  But if you go
that way, then please don't complain if things break (and please
mention it if you do).

Hope that helps.


[1] You can still install them elsewhere with help of DESTDIR installs.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]