Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 80781 - SRPMS: perl uses itself for installing, previous(system) libperl.so is used when rebuild
Summary: SRPMS: perl uses itself for installing, previous(system) libperl.so is used w...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: perl
Version: 8.0
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Warren Togami
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-31 09:49 UTC by Sysoltsev Slawa
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-11 11:48:53 UTC


Attachments (Terms of Use)
Patch which adds LD_PRELOAD to perl call during installation (deleted)
2002-12-31 09:52 UTC, Sysoltsev Slawa
no flags Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.