On 12 October 2015 at 12:09, Matt Turner <matts...@gmail.com> wrote: > On Sun, Oct 11, 2015 at 4:18 PM, Rhys Kidd <rhysk...@gmail.com> wrote: > > On Sunday, 11 October 2015, Matt Turner <matts...@gmail.com> wrote: > >> > >> On Sat, Oct 10, 2015 at 10:30 PM, Rhys Kidd <rhysk...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
