[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