[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: Mon, 11 Jul 2005 16:24:34 -0400

 <address@hidden>Ralf Wildenhues writes:
>Hi Tom,
>* tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST:
>> Hi all, I'm trying to get libtool to link a program that depends on a
>> circular list of static (libtool) libraries.
>> I'm using a command line like:
>> ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include
>> -O0 -o partrj -static *.o ../ui/ ../models/
>> ../share/ ../models/ ../grid/
>> ../fields/ ../share/
>> ../menus/ ../strings/src/
>> ../hash/ ../dbg/ ../t89files/
>> unfortunately this ends up not working because libtool is
>> removing/reordering some of the libraries:
>I presume this is because the libraries have interdependencies listed in
>the respective .la files.

erm.. hopefully? This is all an autoconf/automake generated thing; it
appears I was doing what are called 'libtool convenience libraries'. I
simply pulled out + posted the line that caused problems.

>> g77 -Wall -I../include -O0 -o partrj <bunch of .o files>
>> ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a
>> ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a
>> ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a
>> ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a
>> ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a
>> "--preserve-dup-deps" doesn't seem to have an effect. I also tried
>> remaking the command line using -L and -l options instead of explicitly
>> specifying the .la file, with the same effect of libtool stripping out
>> libraries from the link line.
>Hmm.  Is the package that contains these libraries freely available
>online?  If not: could you show the corresponding link lines for the

unfortunately, no.

>libraries?  (Either the snippets, or whatever `make' makes
>of it as libtool command line; plus libtool's output.)


/bin/sh ../../libtool --mode=link g77 -Wall -I../include/
-pedantic-errors -fno-f90 -fno-automatic -finit-local-zero
-fugly-complex -fugly-init -Wno-globals -g -O2   -o
dbg_basics.lo dbg_bevals.lo dbg_constants.lo dbg_harpol.lo
dbg_interp.lo dbg_position.lo dbg_ivector.lo dbg_vector.lo
ar cru .libs/libSPPdbg.a .libs/dbg_basics.o .libs/dbg_bevals.o
.libs/dbg_constants.o .libs/dbg_harpol.o .libs/dbg_interp.o
.libs/dbg_position.o .libs/dbg_ivector.o .libs/dbg_vector.o
ranlib .libs/libSPPdbg.a
(cd .libs && rm -f && ln -s ../

You'll notice that the above has slightly different flags than what you
would guess based on earlier lines I've included. Since I reported
this, I've determined we don't really /need/ libtool at all, so I
removed it from the project. After that I heard the project was missing
some flags that should be there, from the source code author, so I've
added them in.
The line I just gave above is from me changing one of the Makefile.ams
to use libtool again.

The relevant snippets are:

# old way -- using libtool
libSPPdbg_la_SOURCES= \
      dbg_basics.f \
      dbg_bevals.f \
      dbg_constants.f \
      dbg_harpol.f \
      dbg_interp.f \
      dbg_position.f \
      dbg_ivector.f \
      dbg_vector.f \


The "new way" is the same but s/LTLIBRARIES/LIBRARIES/ and s/la/a/. All
the libaries are (were) built in this same manner.

>> I found a post on libtool-patches from 2002, where someone else had run
>> into this issue. They expected linker flags of -Wl,"-(" <libs> -Wl,"-)"
>> to fix it. I changed my link line above to use these linker flags in
>> the libtool command line, but I still get the same error. It appears as
>> if the patch was never applied (why?)?
>Are you talking about this?

Ooops, sorry! I had thought I included the link; mea culpa. Thanks for
doing the research again for me =)

>I can only guess it was not applied because it's a hack..


>> I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'.
>> What am I doing wrong? How can one link in circular dependencies using
>> libtool?
>Oh, most likely they are broken, but to be honest, I have no idea.  We
>don't have a proper test for them, so we can't expect them to stay
>unbroken.  The reason I have asked for details above is that we may be
>able to generate a decent test case from your situation, and then work
>from that.

Well if theres more I can do to help in building a test case, just let
me know / ask.


reply via email to

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