[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: Framework support in -make
RFC: Framework support in -make
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
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
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:
AUXILIARY_CFLAGS += -I$(I_APPKIT_INCL_DIR)
AUXILIARY_OBJCFLAGS += -I$(I_APPKIT_INCL_DIR)
GUI_LIBS= -L$(I_APPKIT_DIR)/Versions/0.9.0/$(GNUSTEP_TARGET_LDIR) -lAppKit
(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
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
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
libFWName.so.[another version name]
and so on. Routine fixups may be necessary for this to work, as we all
know too well.
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
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, Nicola Pero, 2003/05/09
- Re: RFC: Framework support in -make, Helge Hess, 2003/05/12
- Re: RFC: Framework support in -make, Jeff Teunissen, 2003/05/09