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

[Rhys Kidd]

On 12 October 2015 at 12:09, Matt Turner <mattst88 at gmail.com> wrote:

> On Sun, Oct 11, 2015 at 4:18 PM, Rhys Kidd <rhyskidd at gmail.com> wrote:
> > 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> 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.
>
> Right. Still, I wonder what is responsible for the difference in
> behavior...
>
> > 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.
>
> How about we just s/LDFLAGS/LDLIBS/? That yields
>
> cc -g -O2 -march=native -pipe -std=gnu99 -fopenmp    run.c  -lepoxy -lgbm
> -o run
>
> See if that works on your system.
>
> Thanks,
> Matt
>

Hello Matt,

That approach using s/LDFLAGS/LDLIBS/ also works for me. I like it for
being more terse.

I'll send a v2 of the first of the three patches. Can I add your R-B?

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