Red Hat Bugzilla – Bug 80781
SRPMS: perl uses itself for installing, previous(system) libperl.so is used when rebuild
Last modified: 2007-04-18 12:49:24 EDT
Description of problem:
Ive tried to build perl-5 from source rpm with custom compiler and failed with
5.8.0:/home/users/compiler/brod/compiler/lib ./perl installperl
make: *** [install.perl] Segmentation fault
make: Leaving directory `/home/users/compiler/tmp/rtt/WORK_DIR/BUILD/perl-
make: *** [install] Error 2
error: Bad exit status from /users/compiler/tmp/rtt/WORK_DIR/tmp/rpm-tmp.5294 (%
Here is ./perl executable which was build during build stage. It uses
libperl.so which are also built by build script and placed
in /users/compiler/tmp/rtt/WORK_DIR/BUILD/perl-5.8.0 pointed by
LD_LIBRARY_PATH. But problem here is that built ./perl has hardcoded RPATH
pointed to /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE, where previous
system libperl.so dwells. As RPATH in ELF file prevail LD_LIBRARY_PATH, system
libperl.so will be used despite of fresh one, when perl is started to
execute installperl script. I think this is a bit wrong.
Lets think, when user may rebuild Perl from sources if they already have one
First reason is when system variant of Perl has been broken and/or works
incorrectly, and then user could try to rebuild perl from sources. Second
reason I think is when user is Perl developer and they are trying to do some
changes in it, especially in Perl basics. And third reason is when user has
custom compiler supposed to boost Perl performance. With all these cases
FRESHLY built perl shouldnt use OLD installed libperl.so from prevous build.
This may cause wide variety of errors from linker errors till run-time errors
as for example internal Perl structures/interfaces could change. And as this
error could happen during installation when perl executes system scripts (so
user is assumed to be root), extra security and attention should be applied.
It is a bit hypothetic situation I described because for error appearing old
and freshly built libperl.so should vary in something basic. But this may
disappoint you if you are trying to customize your Perl and changes done in
local libperl.so doesnt affect ./perl as supposed. Or this error could appear
when you used different compilers for building system and local versions of
perl, for example this may happen when users will go on to next version of gcc.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm bp perl.spec
2. change something basic in perl, for example do extra init
Perl_reentrant_init (reentr.c) and assume somewhere in ./perl code this
3. Now starting ./perl before installation complete you may get error because
it will use system installed libperl.so which doesnt have changes in
Perl_reentrant_init (reentr.c) you've done.
Something similar could happen without code change if you use compiler
different enough from gcc.
Installation failed with perl segmentation fault
Succesfully built & installed package
For me was enough to modify Makefile.SH to use perl call with LD_PRELOAD
variable, I'll attach the patch.
Created attachment 88996 [details]
Patch which adds LD_PRELOAD to perl call during installation
This method isn't portable (at least shared libraries support needed in
system). Could be used only for explanation.
this is a known issue, but had not yet been fixed, so your patch is quite
helpful. this issue also causes trouble during the 'make test' phase of the
build and when C headers are translated into ph headers. I've adjusted your
patch slightly and will submit upstream, as this is an issue with all perls that