[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: Framework support in -make
From: |
Jeff Teunissen |
Subject: |
RFC: Framework support in -make |
Date: |
Tue, 06 May 2003 07:34:58 -0400 |
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/
- RFC: Framework support in -make,
Jeff Teunissen <=
- Re: RFC: Framework support in -make, Nicola Pero, 2003/05/06
- Re: RFC: Framework support in -make, Jeff Teunissen, 2003/05/06
- Re: RFC: Framework support in -make, Nicola Pero, 2003/05/07
- Re: RFC: Framework support in -make, Stefan Urbanek, 2003/05/07
- Re: RFC: Framework support in -make, Nicola Pero, 2003/05/08
- Re: RFC: Framework support in -make, Stefan Urbanek, 2003/05/08
- Re: RFC: Framework support in -make, Frederic De Jaeger, 2003/05/08
- Re: RFC: Framework support in -make, Nicola Pero, 2003/05/09
- Re: RFC: Framework support in -make, Helge Hess, 2003/05/12
- Re: RFC: Framework support in -make, Nicola Pero, 2003/05/08