Re: RFC: Framework support in -make

[Jeff Teunissen]

Nicola Pero wrote:

> > 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).

I write makefile code. ;) For framework searches, a shell script or a
purpose-built search executable (such as which_lib in -make) would work
nicely, and suitably cached (so as to only run the program once for each
framework mentioned in *_FRAMEWORKS) it should be rather speedy.

>  - symlinks mean you can move the framework into another directory, and
> it will still work.  It's easy to underestimate this essential point,

Yes, it is easy to underestimate, because it doesn't work now. :)

Currently, if you move a framework, it no longer works (it can no longer
be used to build executables, and the dynamic linker cannot find it),
because the symlinks are now dangling. */Libraries/*/libFrameworkName.so
and friends now point to nonexistant shlibs -- notice that the symbolic
links are relative, and of course it wouldn't help if they were absolute).

With an ELF -rpath system, this is rather easy to fix, and it can be done
automatically (and repeatedly) without fragility.

> 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.

This is also not a problem. The point behind this idea is to make
frameworks self-contained, so that binary distribution becomes easy.

To explain:

I might write and compile a WWWKit framework and distribute it for
little-endian ELF systems (Linux, *BSD/x86, QNX, etc). Any of these
systems that has a modified ld.so will work out of the box, with no
modifications (and without harm from -rpath). On the other ELF systems, as
part of the installation, the admin would run "framework
/path/to/framework.framework" (or something like that). The "framework"
program would seek out all of the shared libraries in the framework and
updates the RPATH entries in their .dynamic sections to point to the
directories that the shlibs are actually in. I could even have multiple
API versions without penalty. And with just a little bit of extra work,
the same framework tool could run on both little-endian and big-endian
systems and modify the shlibs and executables correctly (by doing
byte-swapping for endian as part of the integer modifications).

By running this one command at the shell, the admin has done all of the
work needed to integrate the framework into their system. It's not much
different conceptually from running ranlib on an archive. :)

If there is a binary distribution of both a framework and binaries that
use it, the command must be run on both the framework and the binaries
(with something like: "framework /path/to/fw.framework [version] program",
where "program" can be any ELF object file (including libs and tools) or a
bundle (whether it be a regular bundle or an application).

All of this is something that can be easily done from an Installer app.

With the _current_ symlink scheme, you need to do somewhat the same thing,
but the lack of versioning bites you. You can't have more than one API
version extant, because the versions of the shlibs in Libraries/$(ldir)
are always 1.0.0. Even without using -rpath or similar, versioned shlibs
for frameworks is a big win.

> 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.

-rpath does not hardcode paths -- it adds an explicit path to the shlib
search list...and that path is modifiable by anything that can modify an
ELF object (not difficult). Part of my proposal is to write such a tool,
or modify an existing tool (as I mentioned, there are a few of them
already out there) to suit our needs.

[snip]

>  - 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.

Except for GNUstep, it's exceedingly rare for a package to use either
LD_LIBRARY_PATH *or* ld.so.conf -- because unlike with GNUstep, the
libraries are almost always installed into the standard locations.

ld.so.conf is off-limits to packagers, as is LD_LIBRARY_PATH to most of
them.

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

IMO, there *is* a lot to gain. It simplifies the life of the user and the
admin. It's further simplified by modifying the dynamic linker, but that's
something that could be addressed by GNUstep-specific operating systems.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/