On 30 May 2017 at 22:37, Juan A. Suarez Romero <[email protected]> wrote: > On Fri, 2017-04-28 at 14:14 +0100, Emil Velikov wrote: >> From: Emil Velikov <[email protected]> >> >> In the early days of Xorg and Mesa we had multiple providers of the >> GLAPI. All of those were the ones responsible for dlopening the DRI >> module. Hence it was perfectly fine, and actually expected, for the DRI >> modules to have unresolved symbols. >> >> Since then we've moved the API to a separate shared library and no other >> libraries provide the symbols. >> >> Here comes the picky part: >> It's possible that one uses old Xorg (where libglx.so provides the >> GLAPI) and new Mesa (with DRI modules linking against libglapi.so). >> >> That should still work, since the the libglx.so symbols will take >> precedence over the libglapi.so ones. >> >> I've verified this while running 1.14 series Xorg alongside this (and >> next) patch. >> >> It may seem a bit fragile, but that's of reasonably OK since all of the >> affected Xorg versions have been EOL for years. >> >> The final one being the 1.14 series, which saw its final bug fix release >> 1.14.7 in June 2014. >> >> To ensure that the binaries do not have unresolved symbols add >> -no-undefined and $(LD_NO_UNDEFINED), just like we do everywhere else >> throughout mesa. >> > > > Turns out that this commit is making install to fail when libdrm is > installed in /usr/local/lib. > > > To workaround this, exporting LDFLAGS to "-L/usr/local/lib" fixes the > problem. > > But I guess there should be a better way to fix this. > There's the one we use in Travis [1], although personally I sort of consider this ("-L/path/to/bar.so" becomes "-L/path/to/ -lbar" during install) notourbug. I might give it another look one of these days, since more and more people are mentioning it.
-Emil [1] https://cgit.freedesktop.org/mesa/mesa/tree/.travis.yml#n27 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
