On Fri, 2017-03-10 at 12:11 +0000, Emil Velikov wrote: > On 9 March 2017 at 14:39, Steven Newbury <st...@snewbury.org.uk> > wrote: > > Introduction of zlib compression for the shader cache means > > zlib needs to be explicitly linked to libOSMesa and libstandalone > > otherwise build fails when LTO is used. > > --- > > How exactly are you doing the LTO build ? I build everything LTO, except for a short blacklist where unsupportable. Specifically, on this system my global *FLAGS contain "-flto=8 -fuse-linker-plugin". I have the lto linker plugin symlinked into "/usr/$CHOST/binutils-bin/lib/bfd-plugins/".
I also have have the following env vars set to ensure they are called with the LTO plugin: AR="gcc-ar" NM="gcc-nm" RANLIB="gcc-ranlib" Mesa is not blacklisted, and with the patch, and previous to the compressed shader cache built fine, but otherwise there are undefined zlib symbols. > > The only user of ZLIB is libmesautil.la which in itself uses > ZLIB_LIBS. It does, and that seems to satisfy linking of libmesautil.la, but it doesn't result in the archive containing a static zlib since you're using "-lz" (at least with the output of pkg-config --libs zlib here) not explicitly linking to libz.a. (My understanding.) > Hence as-is patch looks wrong/incomplete, although I might be missing > something ? I guess that depends upon your point of view. To me it's the preferred behaviour to use the system provided dynamic zlib to resolve the symbols at load time.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
