libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool "module" behavior and darwin


From: Guido Draheim
Subject: Re: libtool "module" behavior and darwin
Date: Mon, 25 Nov 2002 11:04:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system binary. And the module libtool
archive is separate from that. Both .la will be able to pick
up the same .lo being compiled along, so it is nothing more
than a single extra link stage in the make process. IOW, on
linux/solaris this would be
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.so
on systems like darwin it would boil down into
  LINK *.lo -o kbackgammon.so
  LINK *.lo -o libkbackgammon.dylib

Getting back to the question that followed from the original
link problem: I am not sure whether the user-binary called
"kbackgammon" does actually need a shared library to be
built from. In the setup above, there would still need to
be installed _two_ libraries into the target system, plus
the dummy binary. Binding the '-module' kbackgammon.la as
'-static' would still push two copies of the same .lo's into
the system.

It seems the original author did want to avoid having two
copies of the program's library objects around, and this is
in fact possible in most elf systems. The rpath will guide
the system loader to find its -module so-library, whereever
that one will end up. It is in fact a dependency on some
system characteristics that are portable among modern
systems being mostly elf based - but breaks when trying to
port kde somewhere else. (btw, does that link-to-module
work with cygwin?)

That limits the portability of kde as whole, perhaps, and
so the presented patch should really be merged back into
kde, taking the burden to make two libraries even on
elf systems.

Still, I am asking myself if it might be in fact a good
idea to guide all systems to link '-module' .la as static,
that is not to give a '-lmodulelib' to the linker but a
'modulelib.a' - on all systems. Atleast, I'd propose to
have a check - and utter a warning message when s.o. is
trying to link a '-module' archive into a system binary.
We could then see if someone comes around and barks at us
what that warning message has to say. That might allow us
to see where too that .so possiblity has been (ab)used.

cheers, guido

Nick Hudson wrote:
On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote:

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.


This was talked about some time ago by Michael Matz and myself.


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.


I have create patches to the KDE build system that solves a related problem that affects NetBSD a.out platforms. I believe they should fix the Darwin problem.

Unfortunately Michael never folded them back into KDE. I guess he is too busy. :(

Nick


------------------------------------------------------------------------

$NetBSD: patch-aa,v 1.1 2002/05/31 14:02:54 skrll Exp $

--- kbackgammon/Makefile.am.orig        Fri Oct  5 12:52:05 2001
+++ kbackgammon/Makefile.am
@@ -2,21 +2,22 @@
 INCLUDES = -I$(top_srcdir)/libkdegames -I$(top_srcdir)/libkdegames/kgame/ 
-I$(srcdir)/engines $(all_includes)
bin_PROGRAMS = kbackgammon
-lib_LTLIBRARIES = kbackgammon.la
+lib_LTLIBRARIES = libkbackgammon_main.la kbackgammon.la
-CLEANFILES = dummy.cpp
-
-kbackgammon_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
+libkbackgammon_main_la_LIBADD = $(LIB_KDEUI) $(LIB_KSYCOCA) -lkdeprint \
                        ./engines/libkbgengines.la
-kbackgammon_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp \
+libkbackgammon_main_la_SOURCES = main.cpp kbg.cpp kbgboard.cpp kbgtextview.cpp 
\
                        kbgstatus.cpp
+kbackgammon_la_LIBADD = libkbackgammon_main.la
+kbackgammon_la_SOURCES = kbackgammon_main.cpp
+
 kbackgammon_la_METASOURCES = AUTO
 kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module -avoid-version
-kbackgammon_LDADD = kbackgammon.la $(top_builddir)/libkdegames/libkdegames.la \
+kbackgammon_LDADD = libkbackgammon_main.la 
$(top_builddir)/libkdegames/libkdegames.la \
                $(LIB_KSYCOCA)
-kbackgammon_SOURCES = dummy.cpp
+kbackgammon_SOURCES = kbackgammon_main.cpp
 kbackgammon_LDFLAGS = $(all_libraries) $(KDE_RPATH)
noinst_HEADERS = version.h kbg.h kbgboard.h kbgtextview.h kbgstatus.h
@@ -34,9 +35,6 @@
 messages: rc.cpp       
        LIST=`find . -name \*.h -o -name \*.hh -o -name \*.H -o -name \*.hxx -o 
-name \*.hpp -o -name \*.cpp -o -name \*.cc -o -name \*.cxx -o -name \*.ecpp -o 
-name \*.C`; \
        $(XGETTEXT) $$LIST -o $(podir)/kbackgammon.pot
-
-dummy.cpp:
-       echo > dummy.cpp
install-data-local:
        rm -rf $(kde_appsdir)/Games/kbackgammon.desktop





reply via email to

[Prev in Thread] Current Thread [Next in Thread]