[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool "module" behavior and darwin
From: |
Nick Hudson |
Subject: |
Re: libtool "module" behavior and darwin |
Date: |
Mon, 25 Nov 2002 10:37:58 +0000 |
User-agent: |
KMail/1.4.3 |
On Monday 25 November 2002 10:04 am, Guido Draheim wrote:
> 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.
Here's what happends... The bulk of the code ends up in the shared library
libkbackgammon_main.la. The kbackgammon.la module and the kbackgammon are
both very small (a single function called main that calls kdemain) and they
both depend on this dynamic library.
> 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?)
I wtill think the original stuff was plain messy.
> 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.
I still don't think this is a burden. The new shared object is very small,
e.g.
$ ls -l /usr/X11R6/lib/*konqueror*.so
-rwxr-xr-x 1 root wheel 4316 Nov 22 16:53 /usr/X11R6/lib/konqueror.so
-rwxr-xr-x 1 root wheel 810685 Nov 22 16:53
/usr/X11R6/lib/libkonqueror_main.so
Your position for getting this sort of fix into the KDE sources is much better
than mine. NetBSD a.out is almost a distant memory - all platforms are now
ELF in the latest release.
Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE
people. http://www.netbsd.org/Documentation/software/packages.html
Nick
- Re: [Fink-devel] Re: libtool "module" behavior and darwin, (continued)
Re: libtool "module" behavior and darwin, Guido Draheim, 2002/11/24
Re: libtool "module" behavior and darwin, Nick Hudson, 2002/11/25
Re: libtool "module" behavior and darwin, Guido Draheim, 2002/11/25
Re: [Fink-devel] libtool "module" behavior and darwin, Max Horn, 2002/11/25