discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Linking setup with gnustep-make 2.0.1 on Solaris


From: Fabian Groffen
Subject: Re: Linking setup with gnustep-make 2.0.1 on Solaris
Date: Tue, 12 Jun 2007 20:38:51 +0200
User-agent: Mutt/1.5.16 (Darwin 8.9.0, VIM - Vi IMproved 7.1)

On 12-06-2007 20:16:01 +0200, Nicola Pero wrote:
> I often had the reverse thought ... ie, why some systems are so keen
> on hardcoding all library paths. ;-)

Suppose you install a lib in a path which is not in the runtime's
linker path (= /usr/local/lib:/usr/lib:/lib ignoring 64-bits attempts on
Linux), like GNUstep does by default
(/usr/GNUstep/System/Libraries/Libraries or something) then you want
every application that uses that library to automatically find it by
"itself" (--rpath), not only after telling it where they are
((DY)LD_LIBRARY_PATH).

Given that LD_LIBRARY_PATH is considered harmful, I really dislike it on
a distro as well.  What if a user sets LD_LIBRARY_PATH him/herself after
sourcing the script?  Suddenly GNUstep doesn't work any more.  What if
GNUstep happens to provide a library that also exist (by the same name
only?) in the main system?  Affected programs will not work any more.
Using runpaths you can just grab the libraries from the place they
should come from.  You force the runtime linker to look into your paths
for every application/library you run.

> Anyway having the option to control this behaviour would be the best
> solution. :-)
> 
> Hardcoding paths can work well when the system is very precisely controlled 
> and defined, such as Apple OS X or a typical GNU distributions with everything
> installed from pre-built packages.

That is, however, not relevant here.  If you would install GNUstep's
libraries in /usr/lib, then you need not to hardcode anything.  Besides
that, if you don't, also those pre-built packages need to have dynamic
binaries that find the right dynamic libraries.

> But if people try to move things around a little bit, hardcoded paths
> can become a pain - using the dynamic linker to dynamically find
> libraries is obviously more flexible (but, if you want, less robust).

I think again this is not relevant.  I still don't see why one would
move binaries around, but if you move binaries in the current position,
you have to update your LD_LIBRARY_PATH.  In case of my --rpath
binaries setting LD_LIBRARY_PATH would work, which would result in the
workaround/hack that LD_LIBRARY_PATH sort of is made for.  In general,
if you move dynamic binaries on a UNIX system, you need to recompile
them, or use some tools like chrpath on ELF systems or install_name_tool
on Darwin.

> Depending on the user/setup, presumably one or the other option would
> make more sense, so being able to configure the behaviour is probably
> what we need. :-)

User configurability is nice.  Disregarding my attempts to make you see
the beauty of run path, I basically like your advice on where we need to
look to insert the right form.  This equals the question of the original
thread poster :)

Thanks!

-- 
Fabian Groffen
Gentoo on a different level





reply via email to

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