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.
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 use libperl.so.