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 <[EMAIL PROTECTED]> _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
