Bug 80781

Summary: SRPMS: perl uses itself for installing, previous(system) libperl.so is used when rebuild
Product: [Retired] Red Hat Linux Reporter: Sysoltsev Slawa <vyatcheslav.sysoltsev>
Component: perlAssignee: Warren Togami <wtogami>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: low Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-11 11:48:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch which adds LD_PRELOAD to perl call during installation none

Description Sysoltsev Slawa 2002-12-31 09:49:24 UTC
Description of problem:
Ive tried to build perl-5 from source rpm with custom compiler and failed with 
error:

LD_LIBRARY_PATH=/users/compiler/tmp/rtt/WORK_DIR/BUILD/perl-
5.8.0:/home/users/compiler/brod/compiler/lib ./perl installperl
make[1]: *** [install.perl] Segmentation fault
make[1]: Leaving directory `/home/users/compiler/tmp/rtt/WORK_DIR/BUILD/perl-
5.8.0'
make: *** [install] Error 2
error: Bad exit status from /users/compiler/tmp/rtt/WORK_DIR/tmp/rpm-tmp.5294 (%
install)

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 
installed.
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):


How reproducible:
sometimes

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 
initialization.
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.
    
Actual results:
Installation failed with perl segmentation fault

Expected results:
Succesfully built & installed package

Additional info:
workaround:
For me was enough to modify Makefile.SH to use perl call with LD_PRELOAD 
variable, I'll attach the patch.

Comment 1 Sysoltsev Slawa 2002-12-31 09:52:24 UTC
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.

Comment 2 Chip Turner 2002-12-31 15:46:36 UTC
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
use libperl.so.