Two questions on building older perls from a git checkout

[jkeenan]

This is a two-part issue. First, some background.

Background

In the course of my work on the core distribution, I often have occasion to build older versions of perl from a git checkout using whatever are the current "vendor" versions of C-compilers. On my Ubuntu Linux 24.04 LTS machine, that means gcc-13 as default, or, if I choose clang, clang-18.

First Question

Suppose I want to build perl-5.30.0 -- what we released just 6 years ago. I say:

$ git clean -dfxq
$ git checkout v5.30.0
$ sh ./Configure -des -Dusedevel -Dcc=gcc-13 && make test_prep
...
gcc-13 -fstack-protector-strong -L/usr/local/lib -o miniperl \
    opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 
./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to build miniperl.  Please run make minitest; exit 1'
Attempt to free unreferenced scalar: SV 0x64fdd62f8cc8.
Segmentation fault (core dumped)
Failed to build miniperl. Please run make minitest
make: *** [makefile:364: lib/buildcustomize.pl] Error 1

This build throws many build-time warnings but ultimately fails even to build miniperl.

Now suppose I try perl-5.32.0 -- released 5 years ago.

$ git clean -dfxq
$ git checkout v5.32.0
$ sh ./Configure -des -Dusedevel -Dcc=gcc-13 && make test_prep
...
./miniperl -Ilib autodoc.pl
./miniperl -Ilib pod/perlmodlib.PL -q
./perl -Ilib -I. -f pod/buildtoc -q
cd t && (rm -f perl; /usr/bin/ln -s ../perl perl)

This build also throws many build-time warnings, but it does complete. (For the moment we'll set aside the question of whether it passes the test suite.)

Now let's repeat this process with clang-18.

$ git clean -dfxq
$ git checkout v5.30.0
$ sh ./Configure -des -Dusedevel -Dcc=clang-18 && make test_prep
...
./miniperl -Ilib autodoc.pl
./miniperl -Ilib pod/perlmodlib.PL -q
./perl -Ilib -I. -f pod/buildtoc -q
cd t && (rm -f perl; /usr/bin/ln -s ../perl perl)

Again, lots of build-time warnings -- but clang-18 completes make for v5.30.0. Similar results for v5.32.0.

Now, I know that 6 years ago I would have been building perl frequently and successfully on an Ubuntu laptop, albeit with an earlier version of the OS and earlier versions of both gcc and clang. So my first question would be: Why I have lost the ability to build perl-5.30 with a more recent version of gcc?

Second Question

I tried to answer that question myself by bisection. Reading the docs, I believed that the following invocation would show me the commit where the build started to fail with the current version of gcc:

perl Porting/bisect.pl -Dcc=gcc-13 \
--start=v5.30.0 \
--end=v5.32.0 \
--target=miniperl make perl

But that invocation assumes I'm looking for the first bad commit, when actually I'm looking for the first good commit.

...
HEAD is now at 0cf01644e9 add new release to perlhist
good - zero exit from make perl
Runner returned 0 for end revision at Porting/bisect.pl line 233.
That took 37 seconds.

So let's reverse the status I'm looking for.

$ perl Porting/bisect.pl -Dcc=gcc-13 \
--start=v5.30.0 \
--end=v5.32.0 \
--expect-fail \
--target=miniperl make perl

This ends inconclusively with:

/usr/bin/ar rc libperl.a op.o     perl.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o   DynaLoader.o
gcc-13 -o perl -fstack-protector-strong -L/usr/local/lib -Wl,-E perlmain.o   libperl.a `cat ext.libs` -lpthread -ldl -lm -lcrypt -lutil -lc 
HEAD is now at 44523d1ffd Update perlhist
bad - zero exit from make perl
Runner returned 256, not 0 for start revision at Porting/bisect.pl line 240.
That took 75 seconds.

I always groan when I see that Runner returned 256, not 0 for start revision message. We have nothing in our bisection documentation that tells me what to do in this circumstance.

So my second question is, How can I get a bisection to work around a 256 return?

[haarg]

The bisect.pl script automatically patches some parts of the perl source to fix exactly this type of problem, so you aren't going to get matching results running with and without bisect.pl.

[wolfsage]

For your first question, Devel::PatchPerl might help. After you've installed it, run patchperl in the perl source tree, it'll guess the version and apply patches, then you can try configure / building.

For me with gcc version 11.4.0, without running patchperl, building fails with make miniperl segfaulting, but after running patchperl it succeeds.

[wolfsage]

So my first question would be: Why I have lost the ability to build perl-5.30 with a more recent version of gcc?

Looks like prior to this commit: https://github.com/perl/Perl5/commit/9f4e6307232229875331a55e44e1245b0b91e219

gcc >= 10 && < 20 was being detected as gcc 1!

[jkeenan]

For your first question, Devel::PatchPerl might help. After you've installed it, run patchperl in the perl source tree, it'll guess the version and apply patches, then you can try configure / building.

For me with gcc version 11.4.0, without running patchperl, building fails with make miniperl segfaulting, but after running patchperl it succeeds.

patchperl was a very helpful suggestion.

$ git checkout v5.30.0

$ patchperl
Auto-guessed '5.30.0'
Patching 'hints/linux.sh'
patching Configure

$ sh ./Configure -des -Dusedevel -Dcc=gcc-13 && make test_prep

patchperl patched Configure and hints/linux.sh. make test_prep completed successfully. I had quite a few failures in t/porting/bench.t, about which I'm not going to fret; otherwise make test_harness PASSed. Thanks.

[jkeenan]

The bisect.pl script automatically patches some parts of the perl source to fix exactly this type of problem, so you aren't going to get matching results running with and without bisect.pl.

I took that as a hint to re-read the documentation in bisect-runner.pl, which led to this attempted invocation:

perl ~/gitwork/perl/Porting/bisect.pl -Dcc=gcc-13 \
--start=v5.30.0 \
--end=v5.32.0 \
--expect-fail \
--all-fixups \
--target=miniperl make perl

But it still terminated like this:

HEAD is now at 44523d1ffd Update perlhist
bad - zero exit from make perl
Runner returned 256, not 0 for start revision at /home/jkeenan/gitwork/perl/Porting/bisect.pl line 240.

So I guess my immediate question is: "What is the significance of the 256 exit code and can I work around it?"

[wolfsage]

If you're trying to bisect "when did compiling perl fail", then based on the documentation I think you want --test-build

[jkeenan]

If you're trying to bisect "when did compiling perl fail", then based on the documentation I think you want --test-build

Well, I'm actually asking, When did compiling perl start to succeed?. So I presume I would need an --expect-fail in there. I tried this:

perl ~/gitwork/perl/Porting/bisect.pl -Dcc=gcc-13 \
--start=v5.30.0 \
--end=v5.32.0 \
--expect-fail \
--all-fixups \
--test-build
Your branch is up to date with 'origin/blead'.
Note: switching to '796e9a638d2e675de53933d2b3cc114d634cae4f'.
...

... and observed that Configure, at least, got patched on each round:

...
HEAD is now at 0cf01644e9 add new release to perlhist
patching file Configure
Hunk #1 succeeded at 2200 (offset -15 lines).
Hunk #2 succeeded at 2275 (offset -15 lines).
First let's make sure your kit is complete.  Checking...
...

... but the program ended with:

...
HEAD is now at 44523d1ffd Update perlhist
bad - could build test_prep
Runner returned 256, not 0 for start revision at /home/jkeenan/gitwork/perl/Porting/bisect.pl line 240.
That took 119 seconds.

So I'm still puzzled about How can I get a bisection to work around a 256 return?