If user updates the his system only partially so that perl-Errno does
not match perl-libs and the two were built on different kernel, using
Errno will fail:
Errno architecture (x86_64-linux-thread-multi-4.7.9-200.fc24.x86_64) does not match executable architecture (x86_64-linux-thread-multi-4.6.4-301.fc24.x86_64) at /usr/lib64/perl5/Errno.pm line 11.
After building extensions, Makefile builds documentation by executing
the new perl. Because we version libperl.so soname, we need to
precreate a symlink from the soname to ./libperl.so so that the new
perl can be executed. Otherwise this happens:
LD_LIBRARY_PATH=/builddir/build/BUILD/perl-5.24.0 ./perl -Ilib -f pod/buildtoc -q
./perl: error while loading shared libraries: libperl.so.5.24: cannot open shared object file: No such file or directory
This did not appear on upgrade from previous perl version because perl
build script sets LD_PRELOAD in addition if libperl.so exists in the system.
There was an one-line mistake in the following comit. The dependency
on perl's name-version without release number could never been
satisfied.
commit fde8b38ed3
Author: Marcela Mašláňová <mmaslano@redhat.com>
Date: Mon Aug 13 14:05:08 2012 +0200
Define perl_compat by macro for rebuilds.
Sub-packages depend on compat rather than on nvr.
The dependencies are stored in gendep.macros file. The file be
regenerated from an RPM build log by ./generatedependencies tool.
The intended work flow is to build a new perl with RPM Perl dependency
generator available locally. Then use this ./generatedependencies tool to
convert the discovered dependencies into the gendep.macro file. Then it's
possible to build the new perl even without the RPM Perl dependency
generator available in the build root while the resulting binary
packages will still posses all dependencies.
The reason is standard perl-genererators is written in the Perl thus
perl-generators must run-require perl. Therefore there is
a build cycle. One could rewrite perl-generators.spec so that it did
not need perl for building, but the run-time dependency would still be
there.
One could claim the one run-time dependency can be satisfied by older
perl. And that's true and it has been done so until now. But that
would not solve the problem when bootrapping perl to a new architecture
or as an excercise the perl can be built without any prior perl
available (required by paranoid users). With pregenerated
dependencies, one can implement real bootstrap.
(Ultimate solution would be reimplement RPM Perl generators in C.)
We do not insert perl-ExtUtils-MM-Utils into perl-core because this is
not a core module. It's a Fedora extension.
Run regen/lib_cleanup.pl to regenerate Makefile.SH and other scripts
to pass porting/regen.t because of addedd ExtUtils/MakeMaker/MM/Utils.pm file.
But we add perl-ExtUtils-MakeMaker dependency on perl-devel beacuse
many XS package would fail to build. The dependency will be weaken
after proper announcement.
Expressing minimal Perl version as "perl >= 1:5.006" is insufficient:
The Perl version is defined by perl-libs, not perl.
Modules requiring specific Perl but no perl interpreter should not
pull in the perl package.
The epoch numbers are tedious to synchronize.
The auto-generated value is not normalized (1:5.006001).
After this change we will update perl-generators to produce
perl(:VERSION) dependency instead and we will rebuild perl and
perl-Exporter again to leverage this capability.
This is a temporary hack until we find the real cause. /usr/bin/perl
linked with -pie causes failures to:
perl-smartmatch-engine-core
perl-Algorithm-CurveFit
perl-B-Utils
perl-PDL-Graphics-PLplot
One could blame poor XS modules, but perl-Algorithm-CurveFit is
pure perl code with no XS modules. So the bug is somewhere in the
perl.
