On 25/01/18 15:58, Florian Weimer wrote:
On 01/25/2018 04:37 PM, Petr Pisar wrote:
On 2018-01-25, Daniel P Berrangé <berra...@redhat.com> wrote:
Not neccessarily - with perl, the APIs used by extensions are actually
in libperl.so, not /usr/bin/perl, and the extensions link to libperl.so
So perl binary modules ought to still build without undefined symbols,
as IIUC they're not relying on things in /usr/bin/perl
Perl fails too
<https://kojipkgs.fedoraproject.org/work/tasks/5805/24425805/build.log>.
While extensions link to libperl.so that itself links to libpthread.so
that defines pthread_getspecific symbol, the extensions linking fails
because they use dTHX macro, provided by included thread.h via perl.h,
that expands to pthread_getspecific.
In other words it looks like -z defs requires that all used symbols
are provided by directly linked libraries. I.e. we will have to patch
Perl so that extensions add -lptrhread to the linker flags.
Interesting. This leads to:
$ eu-readelf --symbols=.dynsym /usr/lib64/perl5/auto/POSIX/POSIX.so |
grep specific
52: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF
pthread_getspecific
So the symbol version is missing, and there is no guarantee for
compatibility with future glibc versions. 8-(
This is exactly the kind of problem -z defs intends to catch.
There seems to be a similar issue with perl extensions that use C++
failing to link due to missing libstdc++ symbols, eg:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24412387
I think in that case the issue is that libgdal is linked to libstdc++
but the perl GDAL.so module was wound up with direct references to
symbols in libstdc++ but isn't linking to it directly.
So I think that needs a fix in gdal rather than changing the default
libraries linked by perl.
In fact I guess the link should really use g++ not gcc? Not sure how
easy that is to do in a perl extension build...
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
