[Top][All Lists]

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

Re: how to use circular dependencies

From: tom fogal
Subject: Re: how to use circular dependencies
Date: Wed, 10 Aug 2005 15:52:07 -0400

I have devised a test for this. More near the bottom, in the
appropriate context.

 <address@hidden>Ralf Wildenhues writes:
>Hi Tom,
>* tom fogal wrote on Wed, Aug 10, 2005 at 04:58:50PM CEST:
>>  <address@hidden>Ralf Wildenhues writes:
>> >list.  From your response below (you stated that you did not need
>> >libtool after all),  I gathered that this bug report is not so urgent
>> >resp. that without using libtool things would work for you.  More below.
>> Well yes and no =). The post I made on the this list a little while
>> back was for a work project, and I eventually found I didn't really
>> need libtool and worked around it that way. Now I'm trying with a
>> different, personal project that happens to have circular dependencies
>> too, but theres no way I can avoid circular dependencies here =)
>Ah, ok.

Actually, this shouldve read "personal project that happens to have
circular dependencies too, but theres no way I can avoid libtool", but
you seem to have picked up what I meant and not what I said, anyway =)

>> >* tom fogal wrote on Mon, Jul 11, 2005 at 10:24:34PM CEST:
>> >>  <address@hidden>Ralf Wildenhues writes:
>> >> >* tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST:
>> >I don't understand exactly what you mean by this.
>> >Do you have circular dependencies in shared libraries, in static
>> >libraries, or in convenience libraries (or a combination of these)?
>> If I understand what a convenience library is correctly (static library
>> that doesnt get installed), then both these projects are/were stuck
>> with circular dependencies in convenience libraries only.
>Convenience libraries are just collections of objects in an archive.
>When another libtool-created library is linked against the archive, it
>will be added as a whole, i.e., each object in the convenience lib will
>be present in the output library (like the GNU ld --whole-archive
>option).  When a program is linked against it, it will behave just as if
>you link against a plain old archive -- each used symbol will be linked
>Does this make matters clear?

This is a \emph{lot} clearer after looking up what --whole-archive does.
Thank you. I think the --whole-archive reference would be a good thing
to mention in the documentation. Maybe thats just my $0.02 though...

>> >> address@hidden@lib/
>> >                     ^^
>> >I believe there is a slash (/) missing here.
>> Its been too long for my little brain to remember clearly, but I
>> vaguely remember having that slash there and seeing an extra / during
>> builds. The build didn't seem to care about it, but it was
>> aesthetically displeasing to me...
>> Anyway let me verify that before you quote me on it =)
>If you can let us reproduce it, we can either fix it or point out the
>mis-use.  :)

With the below as part of a

### /src/develop/ snippet ###
partrj_LDADD= \
        ../ui/libParTrjUI.a \
        ../grid/libSPPgrid.a \
        ../models/libSPPModels.a \
        ../share/libShare.a \
        ../fields/libSPPFields.a \
        ../menus/libParTrjMenu.a \
        @address@hidden/strings/src/libSPPStrings.a \
        ../hash/libHash.a \
        ../dbg/ \
        ../t89files/libSPPt89.a \
### /src/develop/ snippet ###

I get the following build output:

### '$ make' output snippet ####

Making all in develop
make[3]: Entering directory
/bin/sh ../../libtool --mode=link g77 -Wall -I../include/

<snip -- bunch of object files + compiler options>

write_rkt.o write_rvt.o xyzstart.o ../ui/libParTrjUI.a
../grid/libSPPgrid.a ../models/libSPPModels.a ../share/libShare.a
../fields/libSPPFields.a ../menus/libParTrjMenu.a

../..//srcs/strings/src/libSPPStrings.a ../hash/libHash.a

../dbg/ ../t89files/libSPPt89.a ../models/libSPPModels.a

### '$ make' output snippet ####

emphasis lines added.

If I get rid of the '/' after the '@', making the line

        @address@hidden/strings/src/libSPPStrings.a \

I get:

### '$ make' output with no trailing / ###

Making all in develop
make[3]: Entering directory
/bin/sh ../../libtool --mode=link g77 -Wall -I../include/

<snip -- bunch of object files + compiler options>

write_rkt.o write_rvt.o xyzstart.o ../ui/libParTrjUI.a
../grid/libSPPgrid.a ../models/libSPPModels.a ../share/libShare.a
../fields/libSPPFields.a ../menus/libParTrjMenu.a

../../srcs/strings/src/libSPPStrings.a ../hash/libHash.a

../dbg/ ../t89files/libSPPt89.a ../models/libSPPModels.a 

### '$ make' output with no trailing / ###

again, emphasis lines added.

This is an autoconf + automake + libtool project, so its fully possible
I'm screwing things up in a or something. 'grep' tells me
I'm not doing anything totally braindead though, like overwriting it.

In any case, the result is the same with or without the extra slash.

>> >> Well if theres more I can do to help in building a test case, just let
>> >> me know / ask.
>> >
>> >It would save us some work if you could create a small/minimal test case
>> >project which exhibits your failure.  I can't guarantee a quick fix
>> >though, I haven't delved into the deplibs code for a while and it's
>> >quite intricate.
>> Okay. Would it suffice if I made a minimal project that demonstrates
>> the behavior?
>That would still save a lot of work, yes.

Okay, took a bit longer than I anticipated but I got something that is
much smaller and still demonstrates the issue. You can grab it at:

It includes a 'makefile' and a 'makefile.working'. The former uses
libtool and fails to link because libtool strips off a couple of
libraries. The latter works fine, although it lists some libraries
multiple times.

Its basically three directories (liba, libb, libc...) that are built
into static libraries. liba needs a symbol from libc, libb needs
symbols from both liba and libc, and libc needs symbols from both liba
and libb.

One thing that I found out when doing all of this is that it seems
impossible to create circular dependency issues when the static archive
is comprised solely of one object file. I had to split a library into
multiple .c files, and thus of course multiple .o's, before I could
produce a dependency problem.

>> I'm not sure I completely understand the libtool tests,
>> but it seems there is a series of sub-projects that are run by shell
>> scripts in the tests/ directory...
>We're trying to move away from that long-term (see the Autotest test
>suite in CVS HEAD Libtool if you like).

I'm not really familiar with autotest, so I probably won't dive into
this... sorry.

Thanks again for all your efforts on this!


reply via email to

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