|
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 Live.com. Check it out! |
[Prev in Thread] | Current Thread | [Next in Thread] |