bogus FAILs from mmix ld testsuite

[Jan Beulich]

On 18.11.2025 00:39, Alan Modra wrote:
> On Mon, Nov 17, 2025 at 05:04:47PM +0100, Jan Beulich wrote:
>> On 17.11.2025 16:27, Andreas Schwab wrote:
>>> On Nov 17 2025, Jan Beulich wrote:
>>>
>>>> .../ld/.libs/ld-new: tmpdir/bpo-7.o:(.text+0x2): undefined reference to `areg'
>>>> failed with: <.../ld/.libs/ld-new: tmpdir/bpo-7.o:(.text+0x2): undefined reference to `areg'>, expected: <^[^c][^h][^i][^l][^d].* undefined reference to `areg'$>
>>>
>>> What are the real first five characters of the message?  Because, if any
>>> of them happens to match a character in "child" the match will fail.
>>
>> The path starts with /home/jbeulich. (Also this wouldn't change when re-running
>> "make check", I suppose.
> 
> The 'h' in /home doesn't match the regex.

Oh, I was really blind then.

>> Yet as said, the re-run doesn't hit the same FAILs.)
> 
> Are you sure about that?  I consistently get fails if building mmix
> with --enable-shared, because then the ld-new file name is given as an
> absolute path.  My default --disable-shared mmix builds report
> "./ld-new".

Yes, I am sure. And there is a difference between the 1st and 2nd runs: During
the 1st, the path is /home/jbeulich/build/... (where /home/jbeulich/build is a
symlink to /build), whereas in the 2nd the path is /build/... (i.e. the symlink
resolved). I've checked my scripts, and I couldn't spot any "canonicalization"
that I may be doing.

Actually the preceding lines in ld.log are identical in both runs, using
./ld-new. Hence I can only assume that the wrapper script (ld/ld-new) which
invokes ld/.libs/ld-new behaves differently in both cases. I was then guessing
it might be a difference in the two "make check" invocations. On the first run
it's invoked from the top-level build dir, and hence doesn't pass -C to make.
Whereas in the 2nd run -C is used (at which point iirc make canonicalizes the
path used). Yet adding a "pwd" command to the check: rule in ld/Makefile.in
reveals the canonicalized path (/build/...) in both cases. IOW I'm still lost
as to where the non-canonicalized path would be coming from.

Anyway - the testcase expectation is clearly bogus, and with that corrected
the issue will go away.

Jan