[Top][All Lists]

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

RE: removing rpath from libtool

From: Wintaki Hagabashi
Subject: RE: removing rpath from libtool
Date: Wed, 24 Oct 2007 21:59:29 +0200

Hi Ralf,
Thanks for the response, much appreciated.  Please see my comments below.
> * 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.

I will look into doing this, unfortunately this is a large corporation and doing so may take a long time.
> > 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.

I understand this and think it makes perfect sense in some situations.  If I am building a new server and installing package X, it works perfect.  But what if you are releasing binaries?  Say you are Oracle for a minute, and you build you code into /development/build/release-1.  Now you package and ship to thousands of people who will install your software in any number of places.  Isn't LD_LIBRARY_PATH the thing to do here?  I'm not sure how else you could handle this?
See, in this particular case the customer does not have a compiler, linker, or make tools.  They want a tar file with binaries that they untar and run.  While not disagreeing with you about LD_LIBRARY_PATH, most every commercial package I have used required modifying LD_LIBRARY_PATH.

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

Do you know where I could learn more about these?
> > 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.

Yes, I would agree, but when the customer calls me up and then says "well why the hell are you looking in /development/build anyway?" I'm not sure what my response is.  True, it is technically a customer issue but in this case, it took them some time to figure it out.  Even ldd would hang trying to mount /development.
> > 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.

Yes, this I agree is great for development.  I have no issues at all here and love this ability.  However, I don't see how it is useful though when releasing binaries.
> > 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).

Thanks, I did see that but wanted to avoid hacking libtool if I could.
> Hope that helps.
> Cheers,
> Ralf

Thanks for the reply, much appreciated.

Get news, entertainment and everything you care about at Check it out!

reply via email to

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