Re: RFC: Framework support in -make

[Nicola Pero]

> At least on ELF systems, the dynamic linker can approximate the needs of
> frameworks by making judicious use of -rpath at compile-time. This
> obviates the need for symbolic links to find the shlibs.

Thanks - it's an interesting idea and I appreciate your suggestions.  I
somewhat quite like them, but I'd keep frameworks implemented using
symlinks for the following reasons -

 - symlinks give you very quick compilation: with -rpath, gnustep-make
would have to do a lot of work to get the flags right (it's easy to
underestimate the complexity of this task untill you actually try 
writing makefile code).

 - symlinks mean you can move the framework into another directory, and it
will still work.  It's easy to underestimate this essential point, because
in real life the problem is not really moving frameworks from one
directory into another on the same machine, but binary distribution
between machines with the same frameworks installed in different dirs.  
Consider what happens when you distribute binaries: if you hardcode paths,
all the frameworks should be exactly in the same location on the user
machine as they were on the machine where the executable was built.  For
example, I keep Renaissance into
/home/nicola/GNUstep/Library/Libraries/xxx (so I can mess it up during
develoment without touching any System/root directory).  I can create
binary executables with that setup, and distribute them - they will work
on any machine, even if they have their Renaissance framework (at the
moment it's a library, but suppose it was turned into a framewoek) into
GNUSTEP_LOCAL_ROOT (which is the default for install) or
GNUSTEP_NETWORK_ROOT (maybe because they mount it from the network).  If
we used -rpath to hardcode the path to Renaissance, then those executables
wouldn't work except on my machine.  Now if you build an application
depending on 10 or 20 frameworks, then it can become a serious problem -
you might have some frameworks in System, other ones in Local, other in
Network, and other in your User area; on the end-user machine, the same
frameworks might be installed, but in different locations, and we don't
want to create tiresome problems to the binary distributors!  Btw,
GNUSTEP_NETWORK_ROOT is particularly problematic if paths are hardcoded -
it's supposed to work out of the box, but if you're using a binary
distribution which has hardcoded paths to GNUSTEP_LOCAL_ROOT everywhere,
it's not going to work.

 - symlinks mean the same build system is used on all platforms, which
makes maintenance easier. :-)


I'm not quite what the advantages of -rpath would be.  If the "advantage"
is you don't need LD_LIBRARY_PATH or ld.so.conf, then that's a
disadvantage for me (because it hampers binary distribution!) - it becomes
a matter of -rpath versus ld.so.conf, and I'm afraid we know that everyone
prefers not to hardcode shared lib paths via -rpath but to use ld.so.conf
instead, so that binary distributions can be done without having to hack
object files during installation on the end-user machine: the libraries
will be found dynamically and automatically by the linker, on each
machine, by using the lookup specified in ld.so.conf.

Difficult to give this handy facility/feature up unless we have *a lot* to
gain from the change. :-)


> Failing that, we can use -rpath or an equivalent to locate things, thereby
> making it more acceptable to package GNUstep (this is a real issue with
> distributions -- they tend to not like environment pollution, especially
> with LD_LIBRARY_PATH).

If they don't like LD_LIBRARY_PATH, then they can use ld.so.conf, which
I'm sure they are happy of doing, since they do it all the time :-)

But I agree maybe we should tackle this a bit more, and simplify
installation (or the installation instructions ?) with an eye on
distribution.

After all, at the moment if you're getting a binary distribution (and if
the binary packages appropriately add the paths to ld.so.conf and run
ldconfig when installed, as any other binary package does), then I suppose
the only thing you need to set to run gnustep tools is the PATH ... to
find them :-)

I suppose that might be simplified by adding a symlink from /usr/bin (or
wherever) into /usr/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/
whenever a tool is installed, then you would not even need to set the
path, and everything would work without environment variables.

Thanks for your comments, which were very useful.