libtool
[Top][All Lists]
Advanced

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

Different content for static and shared library.


From: Peter Ekberg
Subject: Different content for static and shared library.
Date: Mon, 2 Oct 2006 17:00:13 +0200
User-agent: Mutt/1.5.12-2006-07-14

Hello!

(For the record, I think what I'm trying to achieve can be
 solved with libltdl, but I do not wish to use libltdl for
 licensing reasons. I have complete understanding with not
 getting any sympathy for that decision. I'm just asking
 if there is a way out of my linking troubles...)

In a project[1] I'm involved with, we have a core library and
an extensive set of modules. The modules use functions from
the core lib. The modules are loaded with a do-it-yourself
"dlopen"-wrapper (with ports for various OSes, etc etc).

In order to support static linking the build basically does
the following:
 - compile a module
 - collect the pieces and deps in a convenience lib
 - go back, until all modules are done
 - compile the core library
 - link the core library and if static libraries are built,
   include above convenience libs
 - link each convenience lib into a shared module (if shared
   libraries are built)
 - compile and link some demo programs

There is one snag with this, and that is if *both* static and
shared libraries are built, the content and the deps of the
modules are dragged into the shared core library and forms a
pretty fat core with a long list of deps.

I also suspect that it might not be too good that the module
convenience libs are included in two shared libs, but we have
not gotten any failures from that, to my knowledge.

I have included a slimmed down example of the libtool specifics
of the build process for reference. The module have been given
a fake dependency on libz, just to show a dep.

Is there a not too complex way to get a trimmed down shared
library even if building both shared and static libraries at
once?

Is it possible to somehow glue the output from two different
libtool invocations together, to at least not have the code
from the modules in the shared core, even if the depedencies
will leak into the .la file? But this sounds a wee bit
fragile...

Cheer,
Peter

[1] http://www.ggi-project.org/

Attachment: example.tar.gz
Description: application/tar-gz


reply via email to

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