[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 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.



reply via email to

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