[Mesa-dev] [PATCH] util/disk_cache: fix zlib linking with LTO build

[Steven Newbury]

On Fri, 2017-03-10 at 12:11 +0000, Emil Velikov wrote:
> On 9 March 2017 at 14:39, Steven Newbury <steve at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170310/956af150/attachment.sig>