Re: [PATCH] ld: Unify the directory separator on Windows.

On 22.07.2026 10:42, Jan Dubiec wrote:
> This patch is a spin-off of the following discussion:
> https://inbox.sourceware.org/binutils/[email protected]/
> 
> When the linker searches for a file, it constructs the full file name by
> concatenating the search path, the directory separator, and the file name.
> As a result, on Windows users may encounter paths like this:
> 
> [...]
> attempt to open D:/Works/binutils/ld/testsuite/ld-archive\tmpdir/a.o failed
> [...]
> 
> or even like this:
> 
> [...]
> 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
> [...]
> 
> This is a safe change, as the linker has been using forward slashes on
> Windows for a long time,

I'd like to have evidence of this. In an earlier discussion ("ld: Skip
p33265-2 and pr33265-2 tests on Windows") you pointed at a piece of code
in the testsuite, which doesn't qualify as reference here. Is there any
path handling which indeed inserts slashes unconditionally (rather than
properly using ...

> and this piece of code appears to be a leftover
> from the dark Windows 9x era.
> 
> Signed-off-by: Jan Dubiec <[email protected]>
> ---
>  ld/ldfile.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/ld/ldfile.c b/ld/ldfile.c
> index f47e860d437..00fe1d90d44 100644
> --- a/ld/ldfile.c
> +++ b/ld/ldfile.c
> @@ -47,12 +47,8 @@ search_dirs_type *search_head;
>  #ifdef VMS
>  static char *slash = "";
>  #else
> -#if defined (_WIN32) && !defined (__CYGWIN32__)
> -static char *slash = "\\";
> -#else
>  static char *slash = "/";
>  #endif
> -#endif
... this? I hope not.

That said, I'm okay with the code change, but I'd like the description
to be accurate. I'm inclined to suggest to replace that part of the
description with just

"This piece of code appears to be a leftover from the dark Windows 9x
 era, or even earlier."

(as I think even Win9x was already capable of dealing with '/', at least
in the common case. Iirc even newer versions of ancient DOS were capable
of that.)

If you agree, I can commit this with said adjustment.

Jan