libtool
[Top][All Lists]
Advanced

[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




reply via email to

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