<div dir="ltr">On 12 October 2015 at 12:09, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Sun, Oct 11, 2015 at 4:18 PM, Rhys Kidd <<a href="mailto:rhyskidd@gmail.com">rhyskidd@gmail.com</a>> wrote:<br>
> On Sunday, 11 October 2015, Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>> wrote:<br>
>><br>
>> On Sat, Oct 10, 2015 at 10:30 PM, Rhys Kidd <<a href="mailto:rhyskidd@gmail.com">rhyskidd@gmail.com</a>> wrote:<br>
>> > Patchset adds Makefile and documentation improvements.<br>
>> ><br>
>> > I aimed to write these as I would have found most helpful when seeking<br>
>> > to<br>
>> > understand shader-db's operation, as a new Mesa developer.<br>
>> ><br>
>> > First patch resolves the build errors [0] experienced on Ubuntu 15.04<br>
>> > and<br>
>> > permit a simple 'make' to work if the dependencies are met. The<br>
>> > following two<br>
>> > patches improve the documentation of those dependencies.<br>
>> ><br>
>> > [0]<br>
>> > $ cc --version<br>
>> > cc (Ubuntu 4.9.2-10ubuntu13) 4.9.2<br>
>> > ...<br>
>> > $ make<br>
>> > cc -g -O2 -march=native -pipe -std=gnu99 -fopenmp  -lepoxy -lgbm  run.c<br>
>> > -o run<br>
>> > /tmp/ccaZrtAC.o: In function `main._omp_fn.0':<br>
>> > /home/usera/Coding/shader-db/run.c:511: undefined reference to<br>
>> > `epoxy_eglBindAPI'<br>
>><br>
>> I don't understand. It works fine locally with the exact same cc<br>
>> command, with every version of gcc I've used since November of last<br>
>> year.<br>
><br>
><br>
> Hello Matt,<br>
><br>
> It is a link ordering issue in the shader-db Makefile prior to this change.<br>
><br>
> The key bits of the command are:<br>
><br>
> cc -g -O2 ... -lepoxy -lgbm ... [ ... the *.o file ... ]<br>
><br>
> The problem is that -lepoxy and -lgbm need to come after all the *.o files<br>
> on the command line as passed to the linker, because order matters:<br>
> libraries are only searched for unresolved symbols from object files that<br>
> precede them on the command line.<br>
><br>
> This situation is commonly seen when libraries are incorrectly added to<br>
> LDFLAGS. GNU Make is clear in the manual that LDFLAGS is only for:<br>
><br>
>     Extra flags to give to compilers when they are supposed to invoke the<br>
> linker, 'ld', such as -L. Libraries (-lfoo) should be added to the LDLIBS<br>
> variable instead.<br>
><br>
> We can of course use any variable, say LIBS, when pulling the libraries out<br>
> of LDFLAGS. The important part though is that the variable is used after the<br>
> *.o files when setting up the command line.<br>
<br>
</div></div>Right. Still, I wonder what is responsible for the difference in behavior...<br>
<span class=""><br>
> I'm not disputing that the current approach has worked for you on your<br>
> setups thus far, just that it is brittle and not guaranteed to work per this<br>
> explanation. I've provided details of at least one (reasonably vanilla)<br>
> Ubuntu dev environment where breakage has been experienced.<br>
><br>
> I hope this has explained why the approach in the patch should be preferred.<br>
<br>
</span>How about we just s/LDFLAGS/LDLIBS/? That yields<br>
<br>
cc -g -O2 -march=native -pipe -std=gnu99 -fopenmp    run.c  -lepoxy -lgbm -o run<br>
<br>
See if that works on your system.<br>
<br>
Thanks,<br>
Matt<br>
</blockquote></div><br></div><div class="gmail_extra">Hello Matt,<br><br></div><div class="gmail_extra">That approach using s/LDFLAGS/LDLIBS/ also works for me. I like it for being more terse.<br><br>I'll send a v2 of the first of the three patches. Can I add your R-B?<br><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Rhys<br></div></div>