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.
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
