[Fink-devel] libtool "module" behavior and darwin

[Benjamin Reed]

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