[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
>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