Bug 80781 - SRPMS: perl uses itself for installing, previous(system) libperl.so is used when rebuild
SRPMS: perl uses itself for installing, previous(system) libperl.so is used w...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
8.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Warren Togami
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-31 04:49 EST by Sysoltsev Slawa
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-11 07:48:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch which adds LD_PRELOAD to perl call during installation (389 bytes, patch)
2002-12-31 04:52 EST, Sysoltsev Slawa
no flags Details | Diff

  None (edit)
Description Sysoltsev Slawa 2002-12-31 04:49:24 EST
Description of problem:
I’ve 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.

Let’s 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 shouldn’t 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 doesn’t 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 doesn’t 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 04:52:24 EST
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 10:46:36 EST
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.