[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Circular dependencies between shared libraries, an (icky) use case
From: |
Ralf Wildenhues |
Subject: |
Re: Circular dependencies between shared libraries, an (icky) use case |
Date: |
Wed, 11 Nov 2009 07:18:23 +0100 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
Hello Simon,
* Simon Richter wrote on Tue, Nov 10, 2009 at 01:41:27PM CET:
> I have a project with two libraries exposing different levels of detail
> to the user, basically one provides (C++) base classes with some
> functionality, and the other one provides classes derived from those
> with the actual implementation.
>
> Since the latter is going to change often, I'd rather not expose the
> derived interface to anyone who doesn't need it, to save me from
> rebuilding and relinking all applications and bumping SONAME all of the
> time.
>
> Now, the two libraries, let's call them libbase and libderived, have
> mutual references: libbase needs to call into libderived to construct
> the actual object, and libderived needs to call into libbase for
> functions that are implemented in the base classes but called from the
> derived ones.
>
> The desired result is that applications that are content with the base
> interface can link against libbase and ignore libderived, and
> applications that require full access to the derived interface link
> against both libraries. When the derived interface changes, I can then
> bump the SONAME of libderived, and rebuild libbase and all apps that
> directly link against libderived, and get back to a consistent set.
> Is something like this possible using libtool,
You can try adding --preserve-dup-deps to *_LIBTOOLFLAGS to keep
duplicate entries in the link libs, but you might still have to do
tricks with -Wc, or -Wl, anyway.
libtool without link_all_deplibs=no (i.e., everywhere except on Debian
with its patched libtool) will link against all deplibs; this will
destrory your strategy of only rebuilding libbase dependents, unless you
remove or rewrite the libbase.la file, unfortunately.
> and if so, can it be done portably?
Probably not for non-ELF systems. On AIX you can probably get away with
runtimelinking (-Wl,-brtl), on w32 you may have to manually create an
import library stub for whichever library you build second. libtool has
no builtin support for this.
HTH.
Cheers,
Ralf