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

[Emil Velikov]

On 12 March 2017 at 13:30, Steven Newbury <steve at snewbury.org.uk> wrote:
> On Sun, 2017-03-12 at 12:25 +0000, Mike Lothian wrote:
>> For what its worth I compile Mesa using LTO with the gold linker so I
>> don't need to specify -fuse-linker-plugin - everything works fine
>> here
>>
>> CFLAGS="-O3 -march=skylake -pipe -flto=8"
>> CXXFLAGS="${CFLAGS}"
>> LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-flto=8"
>>
>> AR="gcc-ar"
>> NM="gcc-nm"
>> RANLIB="gcc-ranlib"
>>
>>
>> On Sat, 11 Mar 2017 at 16:46 Matt Turner <mattst88 at gmail.com> wrote:
>> > On Sat, Mar 11, 2017 at 7:31 AM, Emil Velikov <emil.l.velikov at gmail
>> > .com> wrote:
>> > > On 10 March 2017 at 13:36, Steven Newbury <steve at snewbury.org.uk>
>> > wrote:
>> > >> 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"
>> > >>
>> > > One should not need these. Have you checked that the issue is
>> > > reproducible w/o them ?
>> >
>> > I think they are necessary
>> >
>> > https://gcc.gnu.org/ml/gcc-help/2012-03/msg00100.html
>> >
>> > (though I don't know under which circumstances precisely)
>> >
>> > FWIW, I agree that this patch looks like a hack.
>
> My fault.  I've a local patch which caused LIBADD to be defined twice
> in the src/util/Makefile.am which caused -lz not to be applied to the
> linking of libmesautil.la.  So my patch is indeed wrong, or at least
> unnecessary.  Interesting that missing symbols showed up where they
> did, in particular with OSMesa.
>
> Apologies.

Thanks for the confirmation Steven. As we'll need hacks/workarounds at
some point in the future, all I'm asking is that they should be
clearly documented if we cannot resolve them otherwise.

-Emil