RFC: Framework support in -make

[Jeff Teunissen]

Executive summary: Frameworks need neither special compiler support nor
dynamic linker support to work well, and their advantages outweigh the
problems.

I've been doing some experimentation into making the libraries into self-
contained frameworks. So far, I have mostly completed an AppKit framework
(the code works perfectly with a few small diffs, but I haven't collected
all of the resources yet), but there are some small issues with
framework support that make this problematic.

First, there is no simple way to link to a framework, even on systems that
can easily support most or all of what is needed to use them (this does
not necessarily mean compiler support, as compiler support is merely a bit
of assistance).

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. On
GNUstep-specific systems like LinuxSTEP, the dynamic linker would not need
this at all, because it would know to look in the right places for the
shared libraries inside a framework...but this is, naturally, outside the
scope of GNUstep proper. However, using -rpath on such systems (again,
assuming ELF) is still harmless, because -rpath merely augments the
existing search path. As a side effect, this makes LD_LIBRARY_PATH and/or
editing of ld.so.conf (where applicable) unnecessary.

I have used a temporary solution in my work. That is, creating a
replacement for gui.make that does something like:

I_APPKIT_DIR=/System/Library/Frameworks/AppKit.framework
I_APPKIT_INCL_DIR=$(I_APPKIT_DIR)/Headers
AUXILIARY_CFLAGS += -I$(I_APPKIT_INCL_DIR)
AUXILIARY_OBJCFLAGS += -I$(I_APPKIT_INCL_DIR)
GUI_LDFLAGS= -Wl,-rpath 
-Wl,$(I_APPKIT_DIR)/Versions/0.9.0/$(GNUSTEP_TARGET_LDIR)
GUI_LIBS= -L$(I_APPKIT_DIR)/Versions/0.9.0/$(GNUSTEP_TARGET_LDIR) -lAppKit
GUI_DEFINE= -DAPPKIT_IS_FRAMEWORK

(0.9.0 and /System are expanded by configure when building the .make)

My suggestion, for ELF systems (that is, most of the systems which can
run GNUstep):

A *_FRAMEWORKS makefile variable, which -make uses to locate frameworks
and expand their locations (remember, frameworks can *only* be located in
the well-known locations).

The expansion would do the following:

Add the location of the framework's headers to the include path. This
requires a symbolic link somewhere, because framework headers include the
name of the framework. Alternately, we could simply relocate the headers
to a subdirectory of Headers/.

Add the location of the framework's platform-based shared libraries to the
compiler's search path.

When linking a framework or a library, add an -rpath statement pointing to
the shlib's installation path. This will propagate to binaries
and other shlibs linking with the framework or library.

Obviously, static framework/library builds need not use any -rpath
constructs, but linking with a statically-built framework would still need
the link path added.

Further, frameworks can even be moved (which isn't really supported on 
OPENSTEP very well) and still work, by using a tool (this *can* be done
automatically or manually, with a slight amount of work, by scanning
binaries and replacing one string in the dynamic section with another
-- there are several programs that do this, chief among them chrpath and
elfhack).

On systems with nothing resembling -rpath, the *_FRAMEWORKS variable would
do little more than add -lFrameworkName to the list of libs needed, since
the symlinks (and thus, LD_LIBRARY_PATH or editing of the dynamic linker's
configuration file) would still be needed.

But even here, there are benefits to be had. Versioning of framework-owned
shared libraries can be done to permit having multiple versions installed
properly.

libFWName.so.[version name]
libFWName.so.[another version name]

and so on. Routine fixups may be necessary for this to work, as we all
know too well.

To summarize:

Distributors can modify their dynamic linkers to support frameworks.

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

Failing that, we can use what support there is for shared libraries and
fake frameworks using them, as has been done in the past.

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