perl5
perl5 copied to clipboard
Perl
-Duserelocatableinc does not adjust $Config{startperl}
From @andk
The testreport http://www.cpantesters.org/cpan/report/68c3f844-864b-11e1-ad29-bc4f42b6749c has test failures because Test::Cmd trusts $Config{startperl} to contain the shebang line for the current perl.
But as you can see below, this perl was compiled with -Drelocateableinc and $^X has been moved away from where it was originally installed to (which can be seen in the -Dprefix argument).
In my opinion startperl should reflect the current path to perl. If this is too difficult or not supported for some other reason, it should be documented that it doesn't.
perl -V
Summary of my perl5 (revision 5 version 15 subversion 5) configuration: Commit id: c071f8d7e26d951a082adc9cd79aae32680c01ae Platform: osname=linux, osvers=2.6.30-1-486, archname=i686-linux uname='linux k75 2.6.30-1-486 #1 sat aug 15 18:14:04 utc 2009 i686 gnulinux ' config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.15.5-200-gc071f8d/09a0 -Dmyhostname=k75 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Uuselongdouble -DDEBUGGING=-g -Duserelocatableinc' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g', cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.4.6', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib /usr/lib64 libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.13' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Nov 26 2011 14:28:17 %ENV: PERL5LIB="" PERL5OPT="" PERL5_CPANPLUS_IS_RUNNING="26478" PERL5_CPAN_IS_RUNNING="26478" @INC: /home/sand/src/perl/repoperls/installed-perls/relo/k75/v5.15.5-200-gc071f8d/09a0/lib/site_perl/5.15.5/i686-linux /home/sand/src/perl/repoperls/installed-perls/relo/k75/v5.15.5-200-gc071f8d/09a0/lib/site_perl/5.15.5 /home/sand/src/perl/repoperls/installed-perls/relo/k75/v5.15.5-200-gc071f8d/09a0/lib/5.15.5/i686-linux /home/sand/src/perl/repoperls/installed-perls/relo/k75/v5.15.5-200-gc071f8d/09a0/lib/5.15.5 .
-- andreas
From @andk
On Sat, 14 Apr 2012 21:12:05 -0700, (Andreas J. Koenig) (via RT) <perlbug-followup@perl.org> said:
I found a total of four suspicious Config values:
installbin installprefix perlpath startperl
All four contain the original value of how this perl was built and should not.
-- andreas
From @jkeenan
On Sun Apr 15 23:54:35 2012, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
On Sat, 14 Apr 2012 21:12:05 -0700, (Andreas J. Koenig) (via RT) <perlbug-followup@perl.org> said:
I found a total of four suspicious Config values:
installbin installprefix perlpath startperl
All four contain the original value of how this perl was built and should not.
In the course of reviewing RT #45155 tonight, I had occasion to configure and build perl (blead) with these arguments:
##### sh ./Configure -des -Dusedevel -Dprefix=/home/jkeenan/tmp -Duserelocatableinc #####
I did not install this Perl. When I inspected config.sh, I got these values for the four keys mentioned above:
##### $ grep -nE '(startperl|installbin|installprefix|perlpath)' config.sh | grep -v installprefixexp 749:installbin='/home/jkeenan/tmp/bin' 754:installprefix='/home/jkeenan/tmp' 886:perlpath='/home/jkeenan/tmp/bin/perl5.19.1' 998:startperl='#!/home/jkeenan/tmp/bin/perl5.19.1' #####
Is this consistent with your bug report? (Doesn't appear to be consistent to me, but I've never actually used 'userelocatableinc'.)
Thank you very much. Jim Keenan
From [email protected]
On 05/26/2013 05:51 PM, James E Keenan via RT wrote:
I found a total of four suspicious Config values:
installbin installprefix perlpath startperl
All four contain the original value of how this perl was built and should not.
In the course of reviewing RT #45155 tonight, I had occasion to configure and build perl (blead) with these arguments:
##### sh ./Configure -des -Dusedevel -Dprefix=/home/jkeenan/tmp -Duserelocatableinc #####
I did not install this Perl. When I inspected config.sh, I got these values for the four keys mentioned above:
##### $ grep -nE '(startperl|installbin|installprefix|perlpath)' config.sh | grep -v installprefixexp 749:installbin='/home/jkeenan/tmp/bin' 754:installprefix='/home/jkeenan/tmp' 886:perlpath='/home/jkeenan/tmp/bin/perl5.19.1' 998:startperl='#!/home/jkeenan/tmp/bin/perl5.19.1' #####
Is this consistent with your bug report? (Doesn't appear to be consistent to me, but I've never actually used 'userelocatableinc'.)
Yes, that is consistent with what Andreas reported and I've observed. Why did it seem inconsistent with the report?
The utility of userelocatableinc is significantly handicapped when those parameters contain hardcoded paths specified at configuration time. The problem arises when the installation is moved from the original location and the parameters are used at runtime.
I spent some time triaging this bug myself before I had to drop it for lack of time. I found that at the time I was investigating there were additional config parameters which contained hardcoded paths even under userelocatableinc. Some of those were clearly harmless, but others appeared to be paths that might be used at runtime and hence probably shouldn't contain hardcoded paths when userelocatableinc is in effect.
From [email protected]
On 05/26/2013 05:51 PM, James E Keenan via RT wrote:
I found a total of four suspicious Config values:
installbin installprefix perlpath startperl
All four contain the original value of how this perl was built and should not.
In the course of reviewing RT #45155 tonight, I had occasion to configure and build perl (blead) with these arguments:
##### sh ./Configure -des -Dusedevel -Dprefix=/home/jkeenan/tmp -Duserelocatableinc #####
I did not install this Perl. When I inspected config.sh, I got these values for the four keys mentioned above:
##### $ grep -nE '(startperl|installbin|installprefix|perlpath)' config.sh | grep -v installprefixexp 749:installbin='/home/jkeenan/tmp/bin' 754:installprefix='/home/jkeenan/tmp' 886:perlpath='/home/jkeenan/tmp/bin/perl5.19.1' 998:startperl='#!/home/jkeenan/tmp/bin/perl5.19.1' #####
Is this consistent with your bug report? (Doesn't appear to be consistent to me, but I've never actually used 'userelocatableinc'.)
Yes, that is consistent with what Andreas reported and I've observed. Why did it seem inconsistent with the report?
The utility of userelocatableinc is significantly handicapped when those parameters contain hardcoded paths specified at configuration time. The problem arises when the installation is moved from the original location and the parameters are used at runtime.
I spent some time triaging this bug myself before I had to drop it for lack of time. I found that at the time I was investigating there were additional config parameters which contained hardcoded paths even under userelocatableinc. Some of those were clearly harmless, but others appeared to be paths that might be used at runtime and hence probably shouldn't contain hardcoded paths when userelocatableinc is in effect.
From [email protected]
Following up with the additional configuration reported to build a more relocatable Perl 5.20.0, from #toolchain:
22:43 < mohawk> ./Configure -de -Dprefix=/usr -Duserelocatableinc -Dinstallsitearch=.../../lib/perl5/site_perl/5.20.0/x86_64-linux -Dinstallsitelib=.../../lib/perl5/site_perl/5.20.0 -Dsitearch='.../../lib/perl5/site_perl/5.20.0/x86_64-linux' -Dsitelib='.../../lib/perl5/site_perl/5.20.0' 22:44 < mohawk> otherwise the "site" stuff ends up non-relocatable
I appreciate this is a niche use case, but we build and ship relocatable Perl as part of a product. I'm building Perl 5.38 and we currently use:
./Configure -esdr \
-Dcc=gcc \
-Duserelocatableinc \
-Duseithreads \
-Dusemulti \
-Dprefix=$XYZZY/perl_538 \
-Dprivlib=.../../lib \
-Darchlib=.../../lib \
-Dsitelib=.../../lib \
-Dsitearch=.../../lib \
-Dotherlibdirs=.../../site/lib
Here, $XYZZY is some temporary directory used on the build system that is not present on end user systems where the product is installed. Unfortunately, $XYZZY/perl_538 ends up hardcoded in $Config{startperl}. This is not a real problem for us, because we always run our Perl scripts like: ../perl64/bin/perl some_script.pl. The shebang line is ignored in this case.
It does cause a problem with a few Perl modules. For example, ExtUtils::Helper makes certain assumptions about $Config{startperl} being a valid path. We don't use ExtUtils::Helper in the shipped product, but it is an indirect dependency of LWP. If the relocatable Perl is copied to a different build system to install modules, ExtUtils::Helper tests fail (correctly!). A workaround is to make a symbolic link.
Here, $XYZZY is some temporary directory used on the build system that is not present on end user systems where the product is installed.
You really should use DESTDIR for that, as documented in INSTALL.
As I understand, -Dprefix sets the runtime path while DESTDIR is just for copying files to a target path. I just tried using -Dprefix=... to see if it works:
./Configure -esdr \
-Dcc=gcc \
-Duserelocatableinc \
-Duseithreads \
-Dusemulti \
[email protected] \
-Dprefix=.../ \
-Dprivlib=.../../lib \
-Darchlib=.../../lib \
-Dsitelib=.../../lib \
-Dsitearch=.../../lib \
-Dotherlibdirs=.../../site/lib
make
make test
make install DESTDIR=$XYZZY/perl_538
Build and test go fine. Installation seems to go fine, although it created the directory $XYZZY/perl_538... (yes, dots were appended there). The shebang line was hardcoded to:
$ head -1 $XYZZY/perl_538.../bin/cpan
#!.../bin/perl
Which (again) is fine for our use limited case but not what you really expect. $Config{perlpath} respects -Dprefix but I haven't tried what effect this has when installing modules:
$ $XYZZY/perl_538.../bin/perl -MConfig -E 'say $Config{perlpath}'
.../bin/perl
Installation seems to go fine, although it created the directory $XYZZY/perl_538... (yes, dots were appended there).
I don't think the -Dprefix=.../ should be used. That's really only for @INC paths.