Hi Tom,
Sorry for the high response latency. I saw your post on the automake
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.
* tom fogal wrote on Mon, Jul 11, 2005 at 10:24:34PM CEST:
> <[EMAIL PROTECTED]>Ralf Wildenhues writes:
> >* 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:
*snip*
> >> 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.
OK.
> /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 libSPPdbg.la
> dbg_basics.lo dbg_bevals.lo dbg_constants.lo dbg_harpol.lo
> dbg_interp.lo dbg_position.lo dbg_ivector.lo dbg_vector.lo
> dbg_vlstrn.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
> .libs/dbg_vlstrn.o
> ranlib .libs/libSPPdbg.a
> creating libSPPdbg.la
> (cd .libs && rm -f libSPPdbg.la && ln -s ../libSPPdbg.la libSPPdbg.la)
>
> 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.
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)?
> The line I just gave above is from me changing one of the Makefile.ams
> to use libtool again.
>
> The relevant Makefile.am snippets are:
>
> # old way -- using libtool
> noinst_LTLIBRARIES=libSPPdbg.la
> libSPPdbg_la_SOURCES= \
> dbg_basics.f \
*snip*
>
> [EMAIL PROTECTED]@lib/libSPPstrings.la
^^
I believe there is a slash (/) missing here.
> The "new way" is the same but s/LTLIBRARIES/LIBRARIES/ and s/la/a/. All
> the libaries are (were) built in this same manner.
*snip*
> >> 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.
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.
Cheers,
Ralf
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
