One of the problems we're running into getting KDE working on Darwin is
libtool's concept of a module, and how it's mapped onto Darwin's
linker behavior.
On Darwin, unlike most other unixen (as far as I'm aware), loadable
modules and dynamic shared libraries are 2 distinctly different
entities, and are treated differently by the dynamic loader. Libtool
translates this difference as: if the libtool command-line passes
-module, it creates a Darwin bundle, otherwise it creates a shared
library. Both are PIC, but bundles cannot be linked against.
To get around issues with prebinding and speed of C++ code loading,
especially on linux, KDE creates many of it's executables as shared
libraries, linked twice, once as a module and once a binary. So the
kbackgammon program is kbackgammon.so and kbackgammon, with main()
existing in kbackgammon.so, and kbackgammon being linked against the
.so and an empty dummy.cpp file to make linkers happy as far as making
a program.
The problem comes when trying to build things the KDE way on Darwin --
a number of things get linked against these modules for other purposes
(sharing code, symbol resolution, etc.) but Darwin can't do that.
Darwin does not allow linking against bundles (modules), only against
shared libraries. By default, probably hundreds of makefiles in KDE
have lines like:
---(snip!)---
kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
-avoid-version
kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
---(snip!)---
...this is a no-no, kbackgammon is trying to link against a bundle, and
bombs with:
---(snip!)---
ld: ./.libs/kbackgammon.so is input for the dynamic link editor, is not
relocatable by the static link editor again
---(snip!)---
I can change every one of these makefiles so that
kbackgammon_la_LDFLAGS doesn't have -module on it, and it builds a
shared library instead, but then KDE takes a (very noticable)
performance hit in dlopening these big shared libraries compared to
dlopening a bundle.
If I remove kbackgammon altogether, and only build the .so, KDE's
dlopening facilities will load the bundle version of kbackgammon.so
just fine, and it's fast, but there's no way to run kbackgammon from
the command-line or another app.
We've been discussing this on the Fink project's irc channel, and it
seem the most feasible solution (barring taking an off-the-cuff
estimate of a 20 or 30% speed hit on loading apps) is to make it so
that if libtool is trying to link against a bundle, it will link
against the .a if it's available instead.
While I and some of the other finkers have hacked on libtool some, I am
not sure any of us even know where to start to implement this behavior
in libtool.
Do you guys have any pointers or suggestions as to where to make these
changes, or a better way of handling this issue?
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
