[Ffmpeg-devel] build systems

Dave Dodge dododge
Thu Sep 22 09:27:16 CEST 2005


On Wed, Sep 21, 2005 at 09:42:57AM +0100, M?ns Rullg?rd wrote:
> Sam Hocevar said:
> > On Tue, Sep 20, 2005, Dave Dodge wrote:
> >> C++ is definitely part of the problem; I've also seen template
> >> explosions where a few lines of code ran gcc out of memory, but I
> >> don't think that was the case here.  libtool also seems to be involved
> >> whenever I notice this sort of incredible object size inflation.
> >
> >    Given that libtool merely calls gcc/g++ to build its .o and .lo
> > files, I would be really interested in what makes you think it could be
> > responsible in *any* way for the large object files you are witnessing,
> > and how any other library building tool would avoid the problem.
> 
> Libtool is responsible for building both .o and .lo files.

I will grant that the gigantic file sizes are probably the fault of
some strange C++ usage.  My ire at libtool for this is mostly due to
circumstantial evidence and may not be warranted, though libtool's
creation of multiple object files and copies does make the problem
worse.

> >> I think libtool sometimes also ends up with multiple copies of the giant
> >> .lo/.la/whatever files in various places, all eating up space
> >
> >    I do not think so.

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.

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

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.

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

- libgd has a dependency on libiconv.  It decided, for some reason
  that remains a mystery, that the way to link libiconv is to list the
  libiconv.so file directly on the link line, rather than using (for
  example) -liconv.

- when libgd runs libtool to generate libgd.la, it hands it that
  libiconv.so file as one of its link options.  Libtool gets confused
  by this (because it's not -liconv) and silently throws it away.
  libgd.la is therefore created without listing the necessary
  dependency on libiconv.

- Anything that later tries to link with that libgd.la (in my case
  graphviz) doesn't include libiconv in the linkage, and fails with
  unresolved symbols.

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.

I found a workaround of using LIBS="-liconv" when configuring libgd,
which somehow intereferes with its libiconv detection to the point
that libtool did encode libiconv.la into libgd.la.  Once I had a
workaround I gave up trying to figure out the real problem.

A few months earlier I had a problem with libtool during a GTK+, Glib,
and ATK upgrade.  Due to the order that things had been done, libtool
had found the wrong version of a library and was propogating it into
later builds of other packages.  This was another case of hours of
experimentation to figure out what was really going on.

On another mailing list I read, just today someone complained about
libtool screwing up library paths in a .la file and causing a bunch
of trouble; my problems with it don't seem to be very new or unique.

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.

                                                  -Dave Dodge





More information about the ffmpeg-devel mailing list