Expected pr24576-1 and pr24576-2 failures on Windows/MinGW

Jan Beulich jbeulich@suse.com
Mon Feb 23 07:29:54 GMT 2026


On 20.02.2026 15:32, Jan Dubiec wrote:
> Currently these test cases fail on Windows/MinGW:
> 
> [...]
> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o 
> tmpdir/default-script.o 
> /d/Works/binutils/ld/testsuite/ld-scripts/default-script.s
> Executing on host: sh -c 
> {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o 
> tmpdir/default-script.o 
> /d/Works/binutils/ld/testsuite/ld-scripts/default-script.s 2>&1} 
> /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -defsym 
> _START=0x800 -T default-script.t -T default-script.t -o tmpdir/dump 
> tmpdir/default-script.o
> Executing on host: sh -c {./ld-new 
> -L/d/Works/binutils/ld/testsuite/ld-scripts  -defsym _START=0x800 -T 
> default-script.t -T default-script.t -o tmpdir/dump 
> tmpdir/default-script.o  2>&1}  /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> succeeded with: <>, expected: <.*default-script.t\)' appears multiple times>
> FAIL: ld-scripts/pr24576-1
> /d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o 
> tmpdir/default-script.o 
> /d/Works/binutils/ld/testsuite/ld-scripts/default-script.s
> Executing on host: sh -c 
> {/d/Works/xcomp/build-binutils-h8300-mingw/ld/../gas/as-new     -o 
> tmpdir/default-script.o 
> /d/Works/binutils/ld/testsuite/ld-scripts/default-script.s 2>&1} 
> /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> ./ld-new   -L/d/Works/binutils/ld/testsuite/ld-scripts  -defsym 
> _START=0x800 -T ././/default-script.t -T default-script.t -o tmpdir/dump 
> tmpdir/default-script.o
> Executing on host: sh -c {./ld-new 
> -L/d/Works/binutils/ld/testsuite/ld-scripts  -defsym _START=0x800 -T 
> ././/default-script.t -T default-script.t -o tmpdir/dump 
> tmpdir/default-script.o  2>&1}  /dev/null dump.tmp (timeout = 300)
> spawn [open ...]
> succeeded with: <>, expected: <.*default-script.t\)' appears multiple times>
> FAIL: ld-scripts/pr24576-2
> [...]
> 
> This is because SAME_INODE macro (called from ldfile_find_command_file() 
> in ld/ldfile.c) returns 0. After browsing gnulib sources IMO it doesn't 
> seem to be easily fixable. Perhaps it has been already fixed in upstream 
> gnulib? I didn't check.

Why would gnulib matter here? Aren't we using a private implementation, in
include/same-inode.h? Which then likely can be improved (may simply be a
result of "! defined __CYGWIN__" not really meaning "Native Windows")?

> Anyway, because duplicated script names IMO are not a major problem, I 
> propose to make these test cases to XFAIL on Windows/MinGW. However I 
> don't know how to do it in an elegant way. At the moment I have 
> something like this im my repo:

Since it's run_dump_test, you'd add suitable #xfail lines close to the top
of the *.d files (see binutils/testsuite/lib/binutils-common.exp, which
has an extensive comment ahead of run_dump_test). But such an #xfail would
need justifying, because we also don't want someone else to observe
unexpected passes.

Jan

> --- a/ld/testsuite/ld-scripts/script.exp
> +++ b/ld/testsuite/ld-scripts/script.exp
> @@ -233,8 +233,20 @@ run_dump_test "pr20302"
>   run_dump_test "output-section-types"
>   run_dump_test "ld-version"
>   run_dump_test "ld-version-2"
> -run_dump_test "pr24576-1"
> -run_dump_test "pr24576-2"
> +
> +# On Windows hosts the following two cases are expected to fail because
> +# SAME_INODE macro called from ldfile_find_command_file() in ld/ldfile.c
> +# always returns 0 and it is unknown if the macro will be fixed, if ever.
> +# So instead of calling run_dump_test we just call dummy xfail to notify
> +# users that there is a problem.
> +if ![string match "*-mingw*" $host_triplet] {
> +    run_dump_test "pr24576-1"
> +    run_dump_test "pr24576-2"
> +} else {
> +    xfail "pr24576-1"
> +    xfail "pr24576-2"
> +}
> +
>   run_dump_test "linker-script-not-found"
> 
>   run_dump_test "segment-start" {{name (default)}}
> 
> 
> Patches and ideas are welcome,
> Jan
> 



More information about the Binutils mailing list