[Top][All Lists]

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

Re: RFC: Framework support in -make

From: Nicola Pero
Subject: Re: RFC: Framework support in -make
Date: Wed, 7 May 2003 15:18:20 +0100 (BST)

Hi Jeff,

thanks for taking time to discuss this issue with me - it's quite

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

Running a shell script or a purpose-built executable *is* slow; running it
once for every framework in *_FRAMEWORKS would be unacceptably slow.

Btw, unfortunately I can't get rid of which_lib - that is one of the very
few shell scripts still used during compilation, but I would get rid of it
if I could find an alternative (symlinks, whatever!). :-)

I suppose what you really want is have which_lib recognize -F arguments
and convert them into a sequence -L -l.  We can't get rid of which_lib
anyway, so that wouldn't add any overhead - you still invoke a single
which_lib per linking stage done, but frameworks would be specified using
-F.  That would sort of solve my issue about -rpath slowing down

Actually, it would be good to have which_lib convert -Fframework into
-lframework anyway, at least when not on Apple.  If we keep symlinks, that
would mean you can add -Fframework and that would work even if the
framework is actually a library ... which sounds nice.

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

That could be done with symlinks as well - you could have a script
updating the symlinks - it's a trivial task - you look up the frameworks,
and add symlinks for the existing ones, and remove dangling symlinks.

Actually, that would be a much more portable script (only manipulating
files and the filesystem, rather than object files internals!). :-)

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

I see your point, but I'm not exactly talking of distribution of

I'm rather talking of distributing a gnustep application, which might
depend on arbitrary frameworks distributed by third parties.

At the moment, you grab the gnustep application binary in the form of an
.app file, you drop it into your Applications folder, you double-click on
it, and the application starts (no setup required).

If it contained library paths hardcoded in the object file, you would need
to hand-edit the hardcoded paths before being able to use the application
- even if you have a script which can do it, it's a complication I'd avoid
to our end users.

In the current setup, frameworks are somewhat not self-contained, but at
least applications are.  You can't drop a framework into your Frameworks/
folder, because it requires setup (setting up/unpacking the symlinks), but
at least you can drop a .app into your Applications/ folder and it works
out of the box.  In your suggestion, frameworks wouldn't still work out of
the box (you need to run a separate shell script btw, which is more
complex than symlinks, because symlinks can be packaged in a tar file, so
are usually very easy to package mechanically into package systems
designed to hold files; moreover you might still need to setup links for
headers), and applications would no longer work out of the box.

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

That doesn't look that simpler/cleaner than a couple of symlinks in a
standard library directory as we have now ... we remove a hack (symlinks),
but we add another hack (all this -rpath, and -rpath updating machinery).  

I feel symlinks are a hack, but easily understood and managed by everyone
- you look at the filesystem, see the symlinks, and here you are you know
how it works; when something doesn't work, even if you know nothing about 
frameworks or gnustep, you would probably see the symlink pointing 
nowhere, you look around and can likely fix it.

-rpath might not be that easy to understand.  When something doesn't work
(those things always happen) it might be very hard for newcomers/GNUstep
newbies to understand what's wrong.

Versioning of libraries can be improved, but I think it can be done using
the standard linking machinery.

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

Or from running ldconfig ? :-)

I prefer using a system-wide well-known utility (such as ldconfig) for
setting up shared libs rather than running our own special setup scripts
for our own special shared libs, which sort of makes it more custom and

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

I agree better versioning could be good, and if you have suggestions to
improve version support (without using -rpath or similar), I'd certainly

I thought there was already some machinery in place to support changing
library versions etc. but it's a while I don't look at that.

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

Ok - but having to run custom tools can be cumbersome and obscure for

> > I'm not quite what the advantages of -rpath would be.  If the
> > "advantage" is you don't need LD_LIBRARY_PATH or, then that's
> > a disadvantage for me (because it hampers binary distribution!) - it
> > becomes a matter of -rpath versus, and I'm afraid we know
> > that everyone prefers not to hardcode shared lib paths via -rpath but to
> > use 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
> Except for GNUstep, it's exceedingly rare for a package to use either
> LD_LIBRARY_PATH *or* -- because unlike with GNUstep, the
> libraries are almost always installed into the standard locations.
> is off-limits to packagers, as is LD_LIBRARY_PATH to most of
> them.

I'm not convinced - when I install an RPM, most of the times, they run
ldconfig.  They don't usually edit, I agree, because they put
all libs in standard directories.

But GNUstep just needs to add a few lines to when the first
package (gnustep-make I suppose) is installed - all later packages need
only do the same as any other binary package: just run ldconfig, because
everything is installed into GNUstep's standard locations, which are in anyway.

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

Ok - I'm happy for you to try to convince me :-) and your proposal *is*
interesting, still I'm personally not convinced yet that it's worth
changing our current setup.

reply via email to

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