fixing the recurring Mesa build problem

Dan Nicholson dbn.lists at
Sun Nov 19 10:42:20 PST 2006

On 11/19/06, Michel Dänzer <michel at> wrote:
> On Sat, 2006-11-04 at 13:48 -0800, Dan Nicholson wrote:
> >
> > I went ahead and fleshed out everything. I still didn't try building
> > since I don't have recent enough libraries and headers to build
> > xserver HEAD.
> Would be nice if you could fix that... I spent a couple of hours today
> trying to wrap this up, but I hit another related problem: As automake
> now doesn't know about the contents of the sources files, the
> nodist_*_la_OBJECTS variables in its output end up not containing the
> symlinked source files, so they don't get compiled. I tried overriding
> nodist_*_la_OBJECTS and *_la_DEPENDENCIES in without
> success. Any ideas for this anyone?

Oh, wow, total showstopper. I hadn't even thought about the libtool
objects. Now I'm seeing exactly what you're seeing. This is really a
difficult problem to attack because, with the existing setup, the Mesa
sources need to be know at dist time and at configure time. And that's
really no different than hardcoding the _la_SOURCES in the xserver's that's happening now.

Here's another ugly fix that might improve the situation slightly. At
least people would have a defined path forward if their Mesa sources
aren't the same as the developer's Mesa sources. The path to Mesa is
given to This goes through and creates a static list of
the Mesa sources from the "sources" files in Mesa. Then automake runs
with these static lists included and can generate the

At configure time, the Mesa tree is pointed to again and the symlink
script is run. Assuming that the Mesa tree at dist and at configure
are different (say a file changed names), make is going to bomb. Then
you could at least just run again pointing to your Mesa
tree, the _la_SOURCES would be updated to what's in your tree, and
hopefully things would work. There could maybe even be a sanity check
at configure time that compares the names of the Mesa sources from
your tree vs. what has distributed.

This might be a complete dead end.

More information about the xorg mailing list