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

[Matt Turner]

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