Closed
Description
The rather obscure and little tested CPAN distribution Class-MethodCache at some point began to experience build-time failures on CPANtesters. First failure report. Excerpt of failure output:
cp lib/Class/MethodCache.pm blib/lib/Class/MethodCache.pm
Running Mkbootstrap for MethodCache ()
chmod 644 "MethodCache.bs"
"/home/cpan/bin/perl/bin/perl5.40.0" -MExtUtils::Command::MM -e 'cp_nonempty' -- MethodCache.bs blib/arch/auto/Class/MethodCache/MethodCache.bs 644
"/home/cpan/bin/perl/bin/perl5.40.0" "/home/cpan/bin/perl/lib/5.40.0/ExtUtils/xsubpp" -typemap '/home/cpan/bin/perl/lib/5.40.0/ExtUtils/typemap' MethodCache.xs > MethodCache.xsc
Please specify prototyping behavior for MethodCache.xs (see perlxs manual)
mv MethodCache.xsc MethodCache.c
cc -c -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2 -DVERSION=\"0.05\" -DXS_VERSION=\"0.05\" -fPIC "-I/home/cpan/bin/perl/lib/5.40.0/x86_64-linux/CORE" MethodCache.c
rm -f blib/arch/auto/Class/MethodCache/MethodCache.so
cc -shared -O2 -L/usr/local/lib -fstack-protector-strong MethodCache.o -o blib/arch/auto/Class/MethodCache/MethodCache.so \
\
/usr/bin/ld: MethodCache.o: in function `XS_Class__MethodCache_mro_isa_changed_in':
MethodCache.c:(.text+0xd8): undefined reference to `Perl_mro_isa_changed_in'
/usr/bin/ld: blib/arch/auto/Class/MethodCache/MethodCache.so: hidden symbol `Perl_mro_isa_changed_in' isn't defined
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make: *** [Makefile:475: blib/arch/auto/Class/MethodCache/MethodCache.so] Error 1
Bisection pointed to 0351a62.
0351a629e71de127cbfd1b142e9eaa6069deabf5 is the first bad commit
commit 0351a629e71de127cbfd1b142e9eaa6069deabf5
Author: Tomasz Konojacki <[email protected]>
Date: Sat Jun 18 07:26:58 2022 +0200
Commit: Tomasz Konojacki <[email protected]>
CommitDate: Sat Jun 18 08:51:14 2022 +0200
hide private functions with __attribute__((visibility("hidden")))
This allows us to enforce API boundaries and potentially enables
compiler optimisations.
@xenu, can you take a look? Does anyone else recall seeing this kind of build-time failure?