Bug 484010

Summary:	dev-perl/perl-tk: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in libz.a(gzio.o)
Product:	Gentoo Linux	Reporter:	Bernd Feige <Bernd.Feige>
Component:	[OLD] Core system	Assignee:	Gentoo Perl team <perl>
Status:	RESOLVED INVALID
Severity:	normal	CC:	base-system
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	emerge --info

Description Bernd Feige 2013-09-06 15:09:46 UTC

When compiling dev-perl/perl-tk-804.31.0, compilation of the bundled PNG package (actually of the libz.a implementation therein) fails with "errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in libz.a(gzio.o)". While this is a bug in its own right, it only surfaces because detecting libpng fails because compilation of PNG/config/has_png.c fails to link.
And that in turn is due to "-lz" being required when linking with the system libpng but "pkg-config --libs libpng" only returns "-lpng16" currently.

So I figure that -lz should not only be present in LIBS.private in /usr/lib64/pkgconfig/libpng.pc but also in LIBS?

Thanks and best regards,
Bernd

Reproducible: Always

Comment 1 Bernd Feige 2013-09-06 15:11:16 UTC

Created attachment 358070 [details]
emerge --info

Comment 2 Samuli Suominen (RETIRED) gentoo-dev

2013-09-06 16:26:15 UTC

For shared linking the NEEDED entries get picked up directly by the compiler from the .so
Thus external libraries should only be listed in Libs.private: for static linking, so they are only exposed with --static flag in `pkg-config`
If they were in Libs: instead of Libs.private: the -lz would get appended to every build, also to non-direct builds and cause overlinking when -Wl,--as-needed is not used
So it would in fact be *wrong* and *harmful* to move -lz from Libs.private: to Libs:

So there is likely just a build system bug in dev-perl/perl-tk. Provide complete build.log of perl-tk

Comment 3 Bernd Feige 2013-09-06 17:31:32 UTC

Sorry, the problem appears to be restricted to compilation with "FEATURES=distcc".
I had tested manually that the automatic resolution of -lz fails.
So anyway, closing and sorry for the noise...
Bernd

PS: I still don't know why the following fails (test case in perl-tk: has_png.c is in /var/tmp/portage/dev-perl/perl-tk-804.31.0/work/Tk-804.031/PNG/config):

# LANG="C" /usr/bin/gcc-4.7.3 has_png.c -I/usr/include/libpng16 -o has_png -lpng16
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccQSlSUu.o: undefined reference to symbol 'zlibVersion'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'zlibVersion' is defined in DSO /lib64/libz.so.1 so try adding it to the linker command line
/lib64/libz.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status