ld: Skip p33265-2 and pr33265-2 tests on Windows

  These tests are expected to fail on Windows because by default maximum path length
is only 260 characters:
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Theoretically the issue could be fixed in two ways, as pointed in the linked article:
   1. using the "\\?\" prefix, but this probably requires a lot of work
   and should be done "binutils-wide", i.e. all tools should be reviewed
   from this point of view,
   2. using manifest file, but this still would require an action from
   the user – they would have to turn on long paths support in the
   Windows registry.

Excerpt from the log:
[...]
PASS: ld-scripts/pr33265-1
/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
spawn [open ...]
./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o 
Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
spawn [open ...]
D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory
failed with: <\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory>, expected: <.*group nested too deeply.*>
FAIL: ld-scripts/pr33265-2
/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
spawn [open ...]
./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-3a -o tmpdir/dump tmpdir/start.o 
Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-3a -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
spawn [open ...]
D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-3b.a: No such file or directory
failed with: <\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-3b.a: No such file or directory>, expected: <.*group nested too deeply.*>
FAIL: ld-scripts/pr33265-3
testcase /d/Works/binutils/ld/testsuite/ld-scripts/script.exp completed in 6 seconds
[...]

ld/
	* testsuite/ld-scripts/script.exp: Skip p33265-2 and pr33265-2
	tests on Windows because default path length is too short.
---
 ld/testsuite/ld-scripts/script.exp | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
  

On 29.06.2026 09:27, Jan Dubiec wrote:
> These tests are expected to fail on Windows because by default maximum path length
> is only 260 characters:
> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
> 
> Theoretically the issue could be fixed in two ways, as pointed in the linked article:
>    1. using the "\\?\" prefix, but this probably requires a lot of work
>    and should be done "binutils-wide", i.e. all tools should be reviewed
>    from this point of view,
>    2. using manifest file, but this still would require an action from
>    the user – they would have to turn on long paths support in the
>    Windows registry.

Based on this, imo the two tests should become XFAILs instead of being excluded
altogether. However, ...

> Excerpt from the log:
> [...]
> PASS: ld-scripts/pr33265-1
> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
> Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o 
> Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory

... where are these absurd paths coming from? If there wasn't this excessive
referencing of the current directory, not problem would arise in the first
place, as it looks.

> --- a/ld/testsuite/ld-scripts/script.exp
> +++ b/ld/testsuite/ld-scripts/script.exp
> @@ -246,7 +246,11 @@ run_dump_test "segment-start" {{name (overridden)} \
>  			       {ld -Ttext-segment=0x10000000}}
>  
>  run_dump_test "pr33265-1"
> -run_dump_test "pr33265-2"
> -run_dump_test "pr33265-3"
> +# On Windows hosts the following two cases are expected to fail because
> +# by default maximum path length is only 260 characters.
> +if { ![ishost *-mingw*] } {
> +    run_dump_test "pr33265-2"
> +    run_dump_test "pr33265-3"
> +}

What about Cygwin? Does this somehow circumvent the issue?

Jan
  

On 29.06.2026 09:54, Jan Beulich wrote:
> On 29.06.2026 09:27, Jan Dubiec wrote:
>> These tests are expected to fail on Windows because by default maximum path length
>> is only 260 characters:
>> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
>>
>> Theoretically the issue could be fixed in two ways, as pointed in the linked article:
>>     1. using the "\\?\" prefix, but this probably requires a lot of work
>>     and should be done "binutils-wide", i.e. all tools should be reviewed
>>     from this point of view,
>>     2. using manifest file, but this still would require an action from
>>     the user – they would have to turn on long paths support in the
>>     Windows registry.
> 
> Based on this, imo the two tests should become XFAILs instead of being excluded
> altogether. However, ...

I agree, but I wanted the patch be "in spirit of" pr24576-1 and 
pr24576-2 related patch which was posted here in February. Also 
binutils' test framework does not offer an elegant way to xfail a test 
depending on *host*. At least I don't know such a way…

> 
>> Excerpt from the log:
>> [...]
>> PASS: ld-scripts/pr33265-1
>> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
>> Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
>> spawn [open ...]
>> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o
>> Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
>> spawn [open ...]
>> D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory
> 
> ... where are these absurd paths coming from? If there wasn't this excessive
> referencing of the current directory, not problem would arise in the first
> place, as it looks.

 From ld/testsuite/ld-scripts/libpr33265-2.a which recursively includes 
itself:
GROUP ( ./././././/libpr33265-2.a )

The recursion depth is set to 100 (MAX_NESTED_GROUP_DEPTH in ldlang.c) 
and that's why the path is so weird. On Linux the tests pass because 
max. path length is ~4KiB there, on Windows they fail because default 
max. path length is ~16x smaller.

The tests pass on Windows when one sets MAX_NESTED_GROUP_DEPTH to a 
small value, e.g. 20.

> 
>> --- a/ld/testsuite/ld-scripts/script.exp
>> +++ b/ld/testsuite/ld-scripts/script.exp
>> @@ -246,7 +246,11 @@ run_dump_test "segment-start" {{name (overridden)} \
>>   			       {ld -Ttext-segment=0x10000000}}
>>   
>>   run_dump_test "pr33265-1"
>> -run_dump_test "pr33265-2"
>> -run_dump_test "pr33265-3"
>> +# On Windows hosts the following two cases are expected to fail because
>> +# by default maximum path length is only 260 characters.
>> +if { ![ishost *-mingw*] } {
>> +    run_dump_test "pr33265-2"
>> +    run_dump_test "pr33265-3"
>> +}
> 
> What about Cygwin? Does this somehow circumvent the issue?

I have no idea. But I bet that there is no such problem.

> 
> Jan

Jan D.
  

On 30.06.2026 10:19, Jan Dubiec wrote:
> On 29.06.2026 09:54, Jan Beulich wrote:
>> On 29.06.2026 09:27, Jan Dubiec wrote:
>>> These tests are expected to fail on Windows because by default maximum path length
>>> is only 260 characters:
>>> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
>>>
>>> Theoretically the issue could be fixed in two ways, as pointed in the linked article:
>>>     1. using the "\\?\" prefix, but this probably requires a lot of work
>>>     and should be done "binutils-wide", i.e. all tools should be reviewed
>>>     from this point of view,
>>>     2. using manifest file, but this still would require an action from
>>>     the user – they would have to turn on long paths support in the
>>>     Windows registry.
>>
>> Based on this, imo the two tests should become XFAILs instead of being excluded
>> altogether. However, ...
> 
> I agree, but I wanted the patch be "in spirit of" pr24576-1 and 
> pr24576-2 related patch which was posted here in February. Also 
> binutils' test framework does not offer an elegant way to xfail a test 
> depending on *host*. At least I don't know such a way…

Can't the [ishost ...] you present use in the .exp file equally be used
in the .d files:

#xfail: [ishost *-mingw*]

?

>>> Excerpt from the log:
>>> [...]
>>> PASS: ld-scripts/pr33265-1
>>> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s
>>> Executing on host: sh -c {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o tmpdir/start.o /d/Works/binutils/ld/testsuite/ld-scripts/start.s 2>&1}  /dev/null dump.tmp (timeout = 300)
>>> spawn [open ...]
>>> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o
>>> Executing on host: sh -c {./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -r --whole-archive -lpr33265-2 -o tmpdir/dump tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
>>> spawn [open ...]
>>> D:\Works\xcomp\build-binutils-h8300-mingw\ld\ld-new.exe: cannot open linker script file D:/Works/binutils/ld/testsuite/ld-scripts\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\././././.\./././././/libpr33265-2.a: No such file or directory
>>
>> ... where are these absurd paths coming from? If there wasn't this excessive
>> referencing of the current directory, not problem would arise in the first
>> place, as it looks.
> 
>  From ld/testsuite/ld-scripts/libpr33265-2.a which recursively includes 
> itself:
> GROUP ( ./././././/libpr33265-2.a )
> 
> The recursion depth is set to 100 (MAX_NESTED_GROUP_DEPTH in ldlang.c) 
> and that's why the path is so weird. On Linux the tests pass because 
> max. path length is ~4KiB there, on Windows they fail because default 
> max. path length is ~16x smaller.
> 
> The tests pass on Windows when one sets MAX_NESTED_GROUP_DEPTH to a 
> small value, e.g. 20.

I see.

>>> --- a/ld/testsuite/ld-scripts/script.exp
>>> +++ b/ld/testsuite/ld-scripts/script.exp
>>> @@ -246,7 +246,11 @@ run_dump_test "segment-start" {{name (overridden)} \
>>>   			       {ld -Ttext-segment=0x10000000}}
>>>   
>>>   run_dump_test "pr33265-1"
>>> -run_dump_test "pr33265-2"
>>> -run_dump_test "pr33265-3"
>>> +# On Windows hosts the following two cases are expected to fail because
>>> +# by default maximum path length is only 260 characters.
>>> +if { ![ishost *-mingw*] } {
>>> +    run_dump_test "pr33265-2"
>>> +    run_dump_test "pr33265-3"
>>> +}
>>
>> What about Cygwin? Does this somehow circumvent the issue?
> 
> I have no idea. But I bet that there is no such problem.

Is this betting of yours backed by any insight you have? (If we're uncertain,
I think at least the commit message should mention this fact. If later someone
notices the same issue on Cygwin, they'd know right away what to do about it.)

Jan