Re: how to use circular dependencies

[Ralf Wildenhues]

Hi Tom,

* tom fogal wrote on Fri, Aug 12, 2005 at 08:56:03PM CEST:
>  <address@hidden>Ralf Wildenhues writes:
> >* tom fogal wrote on Wed, Aug 10, 2005 at 09:52:07PM CEST:

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

Cool.  branch-2-0 bootstrap is currently broken, just FYI.

> >> 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 =)

OK.  I had understood you correctly before.  The issue itself still
makes me wonder.

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

Fine with me.

> >- egrep 'top_(src|build)dir.=' Makefile
> 
*snip*
> 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 = ../..

I just don't see why above could happen then.  I have one more try:
Please send config.log.  Pack it (bzip2 or gzip) if it's large.

I did forget to recommend you a cleaner way of writing this (which may
incidentally also fix it?  Please try):
Use $(top_builddir) instead of @top_builddir@ in Makefile.am.  It is
considered better style, as $(top_builddir) is declared anyway.

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

Boing.  I forgot Autoconf in there, sorry.
(That's what I get for bashing you not to use copy and paste :)

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

Yep.

> 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

I'd make that   .. -I../include ..
(omit the last slash), but it's a stylistic issue.

> -fno-automatic\
>  -finit-local-zero -fugly-complex -fugly-init -Wno-globals"
> 
> AC_SUBST([AM_FFLAGS])

It's fine.

> >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 =)

Point is, in certain modes of operation libtool will change
  ... libc/libc.la
in its input to
      -Llibc -lc
in its output.  Then you'll possibly be wondering about all kinds of
interesting failures.  Yes, I happened across this one while verifying
the last mail I wrote.

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

It's poorly documented.

> Perhaps I could mention this in the forthcoming doc patch, in section
> 4, "Invoking libtool" ?

You may do so (and I'd apply the patch as long as it's true), but I'd
much rather want the limitation removed, and then the fact documented
that both versions are possible.  The situation now is not intuitive.

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

OK.

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

Again, that depends.
- If you depend on other libraries within the same project, you should
*always* use relative paths (and refer to the .la file if any) to them,
like so:

  ... -o libout.la in.lo ../src2/libdep1.la ../src3/libdep2.a

(note the latter -- linking against a static library -- is not
portable and only recommended if libout.la is static-only as well).

- Dependencies against installed libraries are best written as
      -L/path/to/libdir -lname ...


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

It should be your method of choice.

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

Nope, not true.

Modern machines have virtual address spaces, each process lives in its
own, and can thus have a fixed address.  Your knowledge is from DOS
times.  (Wait till you google about PIE executables though..)

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

Ahh, that one.  amd64 is good in this regard: it does not allow non-PIC
code in shared objects.  So it is doing fine.  What you most likely
learned is that it is possible to put non-PIC code in shared objects on
x86.  That's a terrible hack, though, because the x86 is able to do text
relocations.  This means: if two different executable load the same
shared library, the pages with text relocations will be physically
present twice in memory (because they will need different text
relocations).  Not what is wanted.

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

Well, I should probably say that helping takes time away from fixing
bugs (and there are year-old bugs unfixed in Libtool).  OTOH, a
discussion like this one has led me to know about at least 3 open issues
which we might be able to fix eventually.  Plus, if you can supply a
documentation update, that makes up for it far more!  Documentation is
hard to write.

Cheers,
Ralf