On 2/13/20 3:56 PM, hv@crypt.org wrote: > James E Keenan <jkeenan@pobox.com> wrote: > :$ sh ./Configure -des -Dusedevel -Duseithreads \ > : -Dcc="g++7" \ > :-Accflags="-Wl,-rpath=/usr/local/lib/gcc7" \ > :-Aldflags="-Wl,-rpath=/usr/local/lib/gcc7" \ > > After rather more back and forth, it turned out after all to be rather > simple - it goes wrong only if you build perl with -Duseithreads, so > you have to pass that flag to bisect.pl as well. Without that the > script does not die, so the bisector is correctly reporting that it > is not failing as expected at the start revision. > > As such, this invocation: > Porting/bisect.pl --start=a3c77565 --end=a06a4d45 \ > -Dcc="g++7" -Accflags="-Wl,-rpath=/usr/local/lib/gcc7" \ > -Aldflags="-Wl,-rpath=/usr/local/lib/gcc7" -Duseithreads \ > --expect-fail --target t/op/sprintf2.t > .. successfully finds a06a4d45 as the first commit succeeding, and I'm > sure would also find it for a wider range such as v5.31.2 to v5.31.3. > > Hugo > Hugo, many thanks for your investigation. I can confirm that what was missing in the invocation with which I began this thread was '--useithreads'. I know this is not the first time my attempts to bisect some problem have been befuddled by "Runner returned 256, not 0 for start revision". So I'm going to take notes when I/we encounter this again so that we can add to the documentation in Porting/bisect-runner.pl. Thank you very much. Jim KeenanThread Previous | Thread Next