[Ffmpeg-devel] build systems

Sam Hocevar sam
Thu Sep 22 15:46:50 CEST 2005

On Thu, Sep 22, 2005, Dave Dodge wrote:

> Running a quick test, what I find is stuff like this, generated from a
> single "foo.c":
>   foo.lo
>   foo.o
>   .libs/foo.o    <-- this is a _copy_ of foo.o
> When the object files are exploding in size (for whatever reason),
> that extra copy hurts.  I think in the case of Mozilla it was making
> copies of stuff, then putting them into giant archives, which it
> copied, and put into yet bigger archives, and copied again, etc.

   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. Try this instead, it will most certainly create two
different foo.o files:

int a; int foo(void) { return a; }

> > > And when building a shared lib only (which is what
> > > k3d does), .lo and .la files are far from being "giant" (usually far
> > > less than 1KB).
> I'm not sure what you mean by "what k3d does", since the example I
> gave with the 500K .lo file was what k3d _did_ do (at least back in
> 2001).  Perhaps I didn't configure it somehow to avoid this problem,
> and again C++ is probably what's causing the giant object files in
> general.

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

   It is possible that k3d was not doing that in 2001, or even that the
feature did not exist. But that was a long time ago and your hatred
towards libtool should take all the fixed bugs into account :)

> Another difficulty was that when libtool ran the compiler it
> redirected all output to /dev/null.  Which meant when my build ran out
> of disk space, it just stopped dead with no explanation or error
> message.  It wasn't until I ran the c++ command by hand that I got the
> "no space" error; the source tree was so tiny I hadn't even thought to
> check for that.

   Ah, I have had problems with that /dev/null redirection, too. There
is now a flag to disable it.

> > The .la files are just small text files with some instructions to
> > libtool for how to screw up your builds later on.
> This brings me to my most recent run-in with libtool:
>   [...]
> So the cause of the problem is in the libgd build, and it partly
> happens silently in the libtool code.  The effect is triggered much
> later on, while building a completely different package.  Debugging
> this took hours of experimentation, hacking on libtool and its output,
> and poring over logs.

   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.

> Overall, my biggest complaint about libtool is that when it does
> break, debugging it is always extremely tedious and frustrating.
> Patching a broken configure script or .am file is almost trivial in
> comparison.

   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.


More information about the ffmpeg-devel mailing list