[Top][All Lists]

[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:57:24 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Ooops, so I did not read the patch too closely - thanks for
the clarification. IOW, there are now two dummy binaries,
one is the system executable, the other is the dlopen-able
module, and both depend on a single system lib*.la - cute!

just to check back with the darwin'ers: a dlopen().so can
link with a .dylib and everything gets resolved nicely?

cheers, -- guido

Nick Hudson wrote:
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
  LINK *.lo -o
on systems like darwin it would boil down into
  LINK *.lo -o
  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' 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 The 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.

reply via email to

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