[OT] libtool (was: [Ffmpeg-devel] build systems)

[Dave Dodge]

On Thu, Sep 22, 2005 at 03:46:50PM +0200, Sam Hocevar wrote:
> On Thu, Sep 22, 2005, Dave Dodge wrote:
> >   foo.o
> >   .libs/foo.o    <-- this is a _copy_ of foo.o
> 
>    No, it is not a copy of foo.o, it is a version of foo.o that was
> built in PIC mode, and your test code is probably too simple to make
> a difference.

Now that I'm paying closer attention I see what you're talking about.
They had been bit-for-bit equal in my quick test case and I hadn't
noticed the options libtool was using on the compiles.

>    What k3d does is use the AC_DISABLE_STATIC directive to disable the
> double object build and only build the PIC versions (that are needed for
> the static library).

I assume this functionality can only be triggered at configure time,
because there doesn't seem to be any command-line option to libtool to
make it drop the static or dynamic build at runtime.

> > Another difficulty was that when libtool ran the compiler it
> > redirected all output to /dev/null.
>
>    Ah, I have had problems with that /dev/null redirection, too. There
> is now a flag to disable it.

I see the info docs mention -no-suppress, but --help does not.
libtool --help also has the general problem that it's unclear about
where options have to be placed in the command line for libtool to
recognize them.  Yes, I do realize that in most cases people aren't
running libtool by hand.

>    This is because the libgd tarball is shipped with a libtoolised tree
> from 2001. Upstream should be educated into using newer autotools for
> their distribution.

Okay, so it ends up being another "old libtool" problem.

I had a related issue with the jpeg library during the same build: its
bundled config.guess is so old that it fails on ia64.  It didn't help
that the initial symptom of this is that the build spits out error
messages about libtool.

>    I have to agree that debugging libtool issues is not an easy task,
> but there are really less and less of them, especially since version 1.5.

The thing is, debugging a libtool problem can be such an awful
experience that even one incident is enough to ruin its reputation
forever.

For example when you pull up the libtool code not knowing anything
about how it works, search for a top-level variable name, and find it
defined repeatedly with alternating values:

  $ egrep ^build_libtool_libs= libtool
  build_libtool_libs=yes
  build_libtool_libs=no
  build_libtool_libs=yes
  build_libtool_libs=yes
  build_libtool_libs=yes

and then you notice that most of the code is within deeply nested
loops and conditionals that span hundreds if not thousands of lines,
making it very hard to figure out what's actually going to be executed
and where you should put echo statements.  No doubt there's reasons
for all this besides "driving script hackers crazy" :-)

                                                  -Dave Dodge