Re: how to use circular dependencies

[tom fogal]

 <address@hidden>Ralf Wildenhues writes:
>Hi Tom,
>
>* tom fogal wrote on Wed, Aug 10, 2005 at 09:52:07PM CEST:
>> Ralf Wildenhues writes:

<snip>

>> 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...
>
>Ah, ok.  Would you be willing to update the documentation to this end?
>(Be sure to work on the CVS HEAD or branch-2-0 copy of libtool.texi, if
>you do.)

Sure. Probably next week, though.

<snip>
>> >> 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...
>*snip*
>
>> 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 \
>
>You meant to write this here, right?
>|         @top_builddir@/srcs/strings/src/libSPPStrings.a \

Oops. Yes. I had originally done a copy and paste, but then when I got
to the second one I realized that the directory is "srcs" not "src".
Stupidly I fixed it in the Makefile.am and then tried to do a manual
edit here in the email. Bad idea.

To clarify:

      @top_builddir@/srcs/strings/src/libSPPStrings.a \
  gives
      ../..//srcs/strings/src/libSPPStrings.a

  on the link line, and

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

... and I swear those are copy-and-pasted, undefiled by my editor this
time =)

>> 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.
>
>Let's see the following:
>- the exact configure line you issued (copy and paste!)

./configure FFLAGS="-g -Wall -O0" --enable-static --disable-shared

Yes, this is fortran... :|

>- egrep 'top_(src|build)dir.=' Makefile

In the toplevel Makefile:

address@hidden ~/tmp/F77_Projects $ egrep 'top_(src|build)dir.='
Makefile
top_srcdir = .
top_builddir = .

In srcs/develop/Makefile, where partrj_LDADD is and where I got the
Makefile.am snippets from before:

address@hidden ~/tmp/F77_Projects/srcs/develop $ egrep
'top_(src|build)dir.=' Makefile
top_srcdir = ../..
top_builddir = ../..

>Do you modify any of the directory variables mentioned in
>  info 'Preset Output Variables'
>in your configure script?

I'm not very familiar with info, but at the top right after that
command I see "This is the top of the INFO tree", leading me to believe
I'm not looking at what you expected me to look at.

I eventually found what I \emph{think} you wanted me to look at, in
autoconf's infodoc. The first variable it mentions is CFLAGS, then
configure_input, then CPPFLAGS, etc.

Anyway I do not modify anything given in that list. Among things that
might be 'weird', I do have the following in my configure.in:

AM_FFLAGS="-Wall -I../include/ -pedantic-errors -fno-f90
-fno-automatic\
 -finit-local-zero -fugly-complex -fugly-init -Wno-globals"

AC_SUBST([AM_FFLAGS])

<snip>

>Thanks a lot!  It can be fixed without changing libtool, see below.

Oh. awesome =)

>> 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.
>
>First, naming a test library libc is, umm, "interesting" (as would be
>libm, libl, liby, all of which you should avoid on POSIX systems unless
>you provide their functionality, also libC -- often the C++ standard lib).
>This prevents using "-Lpath/to/libc -lc", for example.

Yeah, I was somewhat uncomfortable with the name but it seemed to serve
for the demonstrative purposes I was going for, on my platform. Don't
worry, I haven't used this name in a 'real' project =)

>Second, the flag --preserve-dup-deps is used wrongly: Unfortunately, it
>needs to go before $CC.  We should look into removing this limitation.

Interesting. I was unaware of this restriction.
Perhaps I could mention this in the forthcoming doc patch, in section
4, "Invoking libtool" ?

>Now, there are a couple of ways to solve your problem IMHO, but they
>depend on what you actually want.  This is the crux of the matter: it's
>not clear.
>
>In your example, you create a bunch of convenience archives which have
>mutual (or circular, FWIW) dependencies.  We don't get to see whether
>you want all of these libraries installed later (in which case they
>should _not_ be convenience archives) or not.  Also, while creating the

I have no desire to install the statically built libraries.

>libraries, you do not specify their dependencies (which obviously won't
>work for all dependencies, since libtool currently does not provide a
>way to specify dependency circles).

Okay. This is done via explicit -L/path and -llib options, if I gather
correctly?

>Scenario 1:
>-----------
>You don't actually want liba.a, libb.a libc.a installed.
>Then there is a nice solution to your problem:
>First create all of them as convenience archives, omit all dependencies
>as you do now (convenience archives per definition don't have
>dependencies; they can only be subsumed into other libraries).  Then

Oh, good. Thats simpler =)

>create a convenience archive consisting of the union of all of them:
>
>  $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libabc.la \
>    liba/liba.la libb/libb.la libc/libc.la
>
>and then link your program against libabc.la only.

Well that sounds extraordinarily simple and easy. I should've thought
of this...

<snip -- if want to install add rpath to make !convenience>

>Independently, if you want libabc as static only, be sure to add -static
>to creations of all four libraries, so the convenience archives don't
>contain PIC code.  (Libtool currently has the limitation that it does
>not build two convenience archives, one with PIC and one with non-PIC
>code, when both types of libs are to be built.)

If I can expect

  $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS main.o -o binary libabc.la

to link correctly, I think I will be good. To be honest, I don't think
I understand PIC and non-PIC exactly, because when I learned about PIC,
objects were either PIC or absolute-addressed (I probably learned about
a simplified world). Absolute seemed completely worthless these days
because an 1) operating system actually runs multiple programs, and
thus a program is almost guaranteed to never run in the same spot as
before, and 2) if a program is swapped out and into a different spot,
the operating system must correct all the addresses anyway. It seems
that neither of these would work unless all code was PIC.

Obviously my knowledge is deficient somewhere, because I've noticed
since using an amd64 that using -fPIC or not has a large impact.

>Scenario 2:
>-----------
>You actually want liba.a, libb.a, libc.a installed later (e.g., into
>$libdir) but you do not under any circumstances want shared versions
>of these (neither will your users). 

<snip -- since its not what I want to do>

<snip -- side notes>
<snip -- multiple files needed in static archive for circular
         reference issues>

>Everything clear now?

MUCH more so =). Thanks.

I would have to say that you're one of the best / most
helpful/explanatory/patient maintainers I've come across.

-tom