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.