Re: how to use circular dependencies

[tom fogal]

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
>in.
>
>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/libSPPstrings.la
>> >                     ^^
>> >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 Makefile.am:

### /src/develop/Makefile.am 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/libSPPdbg.la \
        ../t89files/libSPPt89.a \
        ../models/libSPPModels.a
### /src/develop/Makefile.am snippet ###

I get the following build output:

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

Making all in develop
make[3]: Entering directory
`/home/tfogal/tmp/F77_Projects/srcs/develop'
/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/libSPPdbg.la ../t89files/libSPPt89.a ../models/libSPPModels.a

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

emphasis lines added.

If I get rid of the '/' after the '@', making the Makefile.am line
read:

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

I get:

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

Making all in develop
make[3]: Entering directory
`/home/tfogal/tmp/F77_Projects/srcs/develop'
/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/libSPPdbg.la ../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 configure.in 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:

https://apollo.sr.unh.edu/~tfogal/circular.tar.gz

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!

-tom