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.

Attachment: 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

Reply via email to