libtool
[Top][All Lists]

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

>Hi Tom,
>
>* tom fogal wrote on Wed, Aug 10, 2005 at 04:58:50PM CEST:
>>
>> >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:
>> >> >* 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

\/\/
../..//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

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

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

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

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