[Mesa-dev] [PATCH shader-db 0/3] Makefile and documentation cleanup

[Rhys Kidd]

On Sunday, 11 October 2015, Matt Turner <mattst88 at gmail.com> wrote:

> On Sat, Oct 10, 2015 at 10:30 PM, Rhys Kidd <rhyskidd at gmail.com
> <javascript:;>> wrote:
> > Patchset adds Makefile and documentation improvements.
> >
> > I aimed to write these as I would have found most helpful when seeking to
> > understand shader-db's operation, as a new Mesa developer.
> >
> > First patch resolves the build errors [0] experienced on Ubuntu 15.04 and
> > permit a simple 'make' to work if the dependencies are met. The
> following two
> > patches improve the documentation of those dependencies.
> >
> > [0]
> > $ cc --version
> > cc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
> > ...
> > $ make
> > cc -g -O2 -march=native -pipe -std=gnu99 -fopenmp  -lepoxy -lgbm  run.c
>  -o run
> > /tmp/ccaZrtAC.o: In function `main._omp_fn.0':
> > /home/usera/Coding/shader-db/run.c:511: undefined reference to
> `epoxy_eglBindAPI'
>
> I don't understand. It works fine locally with the exact same cc
> command, with every version of gcc I've used since November of last
> year.
>

Hello Matt,

It is a link ordering issue in the shader-db Makefile prior to this change.

The key bits of the command are:

cc -g -O2 ... -lepoxy -lgbm ... [ ... the *.o file ... ]

The problem is that -lepoxy and -lgbm need to come after all the *.o files
on the command line as passed to the linker, because order matters:
libraries are only searched for unresolved symbols from object files that
precede them on the command line.

This situation is commonly seen when libraries are incorrectly added to
LDFLAGS. GNU Make is clear in the manual that LDFLAGS is only for:

    Extra flags to give to compilers when they are supposed to invoke the
linker, 'ld', such as -L. Libraries (-lfoo) should be added to the LDLIBS
variable instead.

We can of course use any variable, say LIBS, when pulling the libraries out
of LDFLAGS. The important part though is that the variable is used after
the *.o files when setting up the command line.

I'm not disputing that the current approach has worked for you on your
setups thus far, just that it is brittle and not guaranteed to work per
this explanation. I've provided details of at least one (reasonably
vanilla) Ubuntu dev environment where breakage has been experienced.

I hope this has explained why the approach in the patch should be preferred.

Regards,
Rhys
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151012/c3197286/attachment.html>