Re: Cyclic dependencies

[Thomas Maier]

Thanks Bob and Benjamin for your quick follow ups.


On Thu, 2003-06-12 at 18:03, Bob Friesenhahn wrote:
> On 12 Jun 2003, Thomas Maier wrote:
> 
> > I think I have a problem with libtool and cyclic dependencies.  Say, I
> > want to build two libraries a.la and b.la.  a uses things from b and
> > vice versa.  When compiling these libs without libtool, first I compile
> > one, then the other.  When linking a program p that uses a *or* b, I
> > have to link p with a *and* b.  Fine.  I only checked that because I had
> 
> Uugh.  Even without libtool, creating libraries with interdependencies
> causes portability problems because some linkers (which even includes
> linkers in older versions of Linux) require that the libraries be
> listed in inverse dependency (left to right) order.  You would find
> that these primitive linkers would require
> 
>  -la -lb -la
> 
> or even
> 
>  -la -lb -la -lb -la
> 
> as many times as required to resolve the cross-dependencies, as they
> are evaluated, in order to resolve all of the symbols.
> 
> Don't do that if you can help it.

Sigh.  It's not a perfect world.  Quoting myself: "I guess as a
linux-only user I am kind of ignorant or, well, at least a newbie to
portability things."  After having spent days reading about that stuff I
already suspected linux does things in a rather modern way.  But I
didn't know it can be *that* bad.  Might you be so kind and give me a
short hint if linux's behaviour is really extraordinary or if systems
with such limited library features are slowly dying away?


> One thing you can do is that if library 'b' can be considered
> subordinate to library 'a' (or treated that way), you can build
> library 'b' as a libtool "convenience library" so that its contents
> are included in library 'a' when library 'a' is linked with library
> 'b'.  Library 'b' is never installed.  This avoids the
> cross-dependency problem, but does that by including the objects from
> library 'b' in library 'a'.

Well, actually I simplified the problem a bit.  I do not only have two
libs, I have a couple.  Say, I have one low level lib a, and two libs b
and c that contain some low level stuff and some high level stuff.  And
then I have a couple of libs d, e, ... 

a and c depend on each other, so do and b, c depends on b, like this:

a <-----> c
^         |
|         |
+--> b <--+


d, e, ... usually use things from a and b, some also from c (when using
a or b they also depend on c, of course).  Solving these inter
dependency problems could quickly be done by putting a, b and c together
into one library, but I do not feel good about that because they contain
classes that do different things (yes, it is C++).  Even ripping out the
low level stuff from a, b and c into some core library doesn't comfort
me too much, although right now I don't see another option.  But maybe
you can enlighten me a bit about convenience libs.

a seems like a clear candidate for being a convenience library as it
contains very and only low level things.  But then I wonder if a
convenience library may be used by several libraries.  The libtool doc
says

"As a rule of thumb, link a libtool convenience library into at most
one libtool library, and never into a program [...]"

If, say, a as a convenience library gets included (that's the way it's
handled by libtool, right?  I have never used them before) into b and c
(and d and e and ...), what happens when I link something with b and c? 
And, even before, what happens when I link c with b when building c?

On the same page "(libtool)Static libraries" the doc also says

"But be careful not to link a single convenience library, directly or
indirectly, into a single program or library, otherwise you may get
errors about symbol redefinitions."

and now I am really confused.  This sounds plain wrong as convenience
libraries were competely useless then.  So it must be my english.  What
is this sentence supposed to tell me?

Thanks for your patience with him who doesn't seem to know anything. 
Not even english :).  Regards, Thomas.

-- 
Thomas Maier <address@hidden>