-
Notifications
You must be signed in to change notification settings - Fork 601
Description
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?