-Duserelocatableinc does not adjust $Config{startperl}

p5pRT commented 12 years ago

Migrated from rt.perl.org#112448 (status was 'open')

Searchable as RT112448$

p5pRT commented 12 years ago

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

p5pRT commented 12 years ago

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

p5pRT commented 11 years ago

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

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From tsibley@cpan.org

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.

p5pRT commented 11 years ago

From tsibley@cpan.org

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.

p5pRT commented 10 years ago

From tsibley@cpan.org

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

vrkosk commented 6 months ago

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.

Leont commented 6 months ago

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.

vrkosk commented 6 months ago

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 \
-Dcf_email=support@matrixscience.com \
-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

Leont commented 6 months ago

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.

Perl / perl5