Re: link_all_deplibs feature

[Alexander Leidinger]

Quoting Bob Friesenhahn <address@hidden> (Sat, 8 Sep 2007 09:08:40 -0500 (CDT)):

> On Sat, 8 Sep 2007, Alexander Leidinger wrote:
> >> Say I'm an innocent user that wants to try out one of your package
> >> on my system where I don't have root privileges.  That's very common.
> >> I can only install in directories neither the runtime linker nor the
> >> link editor will search by default.
> >
> > That's the typical example of the use of LD_LIBRARY_PATH. I assume this
> > not only works without libtool, but even with libtool...
> 
> LD_LIBRARY_PATH is evil.  Lots of software is installed outside of 

LD_LIBRARY_PATH is not useful in a lot of situations, and teaching
users a better way (setting the desired runpath at compile time), but
for a quick and temporary test (and other situations) it is suitable.

> "system approved" areas and not just for "personal" trial use.  It 
> needs to be possible to properly install software without needing to 
> update each system's runtime search path and definitely without using 
> a personal "user" variable like LD_LIBRARY_PATH.

At work we install _everything_ outside the default path. We use
Solaris zones and install each application of our client into it's own
filesystem. This is part of our disaster recovery procedure. We are
talking big iron here. SunFire 25000 and SunFire 15000 machines and
mission critical stuff (as in "if it doesn't work, the client loses
money"). And for the software we compile we don't need LD_LIBRARY_PATH.
We set the correct runpath (-R for gcc) at compile time.

> I have worked in networked environments where several thousand 
> workstations used the network to access open source packages which 
> were not installed in locations ordained by the OS vendor.  Often the 
> location of these packages was project specific, with many on-going 
> projects in the company.
> 
> I have also worked in environments where it was expected that the user 
> needed to set LD_LIBRARY_PATH in order to find libraries, only to find 
> out that it does not work since similar libraries provided by 
> different packages conflict.

LD_LIBRARY_PATH for production use of users is a no-no for us for just
the reasons you wrote. All tools an users has to use has to be self
contained (this means it is ok to set APPNAME_HOME=/foo/bar and such,
but no system/global variables like LD_LIBRARY_PATH).

Apart from that LD_LIBRARY_PATH _is_ useful. If you really know what
you are doing, then it is not evil but a feature which is able to help
you find solutions for problems. I don't object to some handholding for
users which are not much experienced, but not letting experienced users
do what they want is so Micorosoftish. You can put up warning signs
(like I proposed for the cross-compile issue), and/or let the user
confirm his actions, but don't prevent him to do what he wants. This is
unix, after all, if I want to shoot in my foot, it's my own decision
and nobody is allowed to prevent this in unix.

Sorry, but when I hear such absolutisms I get angry. telnet/ssh,
xhost/xauth, ... all are good tools and I don't want to miss any of
them, but then you hear telnet/xhost are evil. They should not be used
in a lot of situations, but there exist situations when someone can use
telnet/xhost without it being a security problem. There are valid uses
for those tools and even for LD_LIBRARY_PATH. If you don't know when to
use them, ok, fine, it's up to you to not use them, but please, let
users which know when it is ok/good to use them actually use them.

Can we go back to the problem at hand instead of talking about policies
please?

Bye,
Alexander.

-- 
RELATIVES!!
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137