[KDE-Darwin] RFC on Makefile.am fixes for (non-portable) linking against libtool modules in KDE

David Leimbach leimy2k at mac.com
Thu Mar 6 05:39:04 GMT 2003


Right.  KDE definitely shouldn't be ELF-dependent.

I don't believe it generally is as there is/has been AIX ports of KDE 
versions.  I can't even
figure out how to make shared libs of any kind on AIX so... :)

Dave Leimbach
On Wednesday, March 5, 2003, at 09:25 PM, Benjamin Reed wrote:

> I had brought this up previously pre-kde-3.1 while working on the 
> MacOSX port of KDE, but as Sam Magnuson and I are working to get our 
> patches all figured out, I figured I'd better bring it up again.
>
> The short version is, libtool libraries built as -module's are not 
> meant to be linked against, but through the magic of the ELF library 
> format and libtool not enforcing this policy, it works 95% of the time 
> anyways.  The big problem with this on MacOSX/Darwin is that Darwin's 
> dynamic loader does *not* allow loading libtool modules (or "bundles", 
> in Darwin terms).
>
> If it was just a few libraries, it would be easy to work around, but 
> KDE's kdeinit library/binary magic does this, and it's all over the 
> place in the KDE code.
>
> The current "fix" looks something like this:
>
> ---(Before:)---
>
> lib_LTLIBRARIES = foo.la
> bin_PROGRAMS    = foo
>
> foo_la_SOURCES = foo.cpp
> foo_la_LDFLAGS = $(all_libraries) -module
>
> foo_SOURCES = dummy.cpp
> foo_LDADD   = foo.la
>
> ---(After:)---
>
> lib_LTLIBRARIES = libfoo_main.la foo.la
> bin_PROGRAMS    = foo
>
> libfoo_main_la_SOURCES = foo.cpp
> libfoo_main_la_LDFLAGS = $(all_libraries)
>
> foo_la_SOURCES = stub_la.cpp
> foo_la_LIBADD  = libfoo_main.la
>
> foo_SOURCES = stub.cpp
> foo_LDADD   = libfoo_main.la
>
> stub_la.cpp: stub.cpp
> 	cat stub.cpp > stub_la.cpp
>
> ---(stub.cpp:)---
>
> extern "C" int kdemain(int, char* []);
>
> int main( int argc, char* argv[] )
> {
>         return kdemain(argc, argv);
> }
>
> ---(fin)---
>
> ...and then the "int main" gets turned into "int kdemain" inside 
> whatever defines main.  (foo.cpp in this case)
>
> As you can see, this way of munging it is perfectly doable, but rather 
> brittle -- people who aren't on platforms like darwin (or, apparently, 
> a.out netbsd) will forget and end up breaking things without knowing.
>
> What I propose is some kind of automake/am_edit trickery to allow this:
>
> ---(new Makefile.am)---
>
> # or kdebin_PROGRAMS maybe?
> kdeinit_PROGRAMS = foo
>
> # foo.cpp contains an int kdemain()
> foo_SOURCES = foo.cpp
> foo_LDADD = <anything but libfoo_main.la>
>
> ---(fin)---
>
> ... it would automatically generate the module and shared library 
> versions of the foo code behind the scenes, with an auto-generated 
> stub.cpp.
>
> Does this seem feasible?  I don't understand automake or am_edit 
> enough to  do this as is, but if someone's willing to dink with it on 
> IRC for a bit to make this auto-generatable, or point me at the right 
> resources to make my own automake macros (which appears to be quite a 
> black art, I've tried), I'm willing to do all the grunt work of fixing 
> the things that need rearranging in the Makefile.am's in the KDE tree.
>
> _______________________________________________
> KDE-Darwin mailing list
> KDE-Darwin at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/kde-darwin





More information about the kde-core-devel mailing list