ld: Unify the directory separator on Windows.

  This patch is a spin-off of the following discussion:
https://inbox.sourceware.org/binutils/20260717101723.1022175-1-jdx@o2.pl/

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, and this piece of code appears to be a leftover
from the dark Windows 9x era.

Signed-off-by: Jan Dubiec <jdx@o2.pl>
---
 ld/ldfile.c | 4 ----
 1 file changed, 4 deletions(-)
  

On 22.07.2026 10:42, Jan Dubiec wrote:
> This patch is a spin-off of the following discussion:
> https://inbox.sourceware.org/binutils/20260717101723.1022175-1-jdx@o2.pl/
> 
> 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 <jdx@o2.pl>
> ---
>  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
  

On 24.07.2026 08:48, Jan Beulich wrote:
> On 22.07.2026 10:42, Jan Dubiec wrote:
>> This patch is a spin-off of the following discussion:
>> https://inbox.sourceware.org/binutils/20260717101723.1022175-1-jdx@o2.pl/
>>
>> 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.

Isn't the absence of any regressions sufficient evidence? There's also a 
simple logical argument: as you noted in another thread, "Clearly, with 
the many slashes in the paths that you quoted, one more slash won't 
break things".

> 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 ...

Sorry, I don't follow. The thread "ld: Skip p33265-2 and pr33265-2 tests 
on Windows" is about a completely different issue — the MAX_PATH 
limitation on Windows. The thread "ld: testsuite: Fix a few 
backslash-related issues on MinGW", on the other hand, deals with 
problems in three specific test cases caused by incomplete regular 
expressions. The two issues are completely unrelated.

This patch is an attempt to address the latter problem in a more general 
way. It was inspired by the following post: 
https://sourceware.org/pipermail/binutils/2026-July/150301.html

> 
>> and this piece of code appears to be a leftover
>> from the dark Windows 9x era.
>>
>> Signed-off-by: Jan Dubiec <jdx@o2.pl>
>> ---
>>   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.
Sure, go ahead!

/J.D.
  

On Fri, 24 Jul 2026, Jan Beulich wrote:

> 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."

 It's not clear what the rationale was as the origin was lost between 
commit 1730ec6b1848 and commit 252b5132c75, which we have no history for 
other than:

Thu Jan 29 16:04:21 1998  Mumit Khan  <khan@xraylith.wisc.edu>

	* ldfile.c (slash): Set to backslash if _WIN32 but not
	__CYGWIN32__.
	(ldfile_open_file_search): If __MSDOS__ or _WIN32, accept a
	leading backslash or a leading x: as an absolute path.
	(ldfile_find_command_file): Use slash rather than / when
	generating name to try.
	* lexsup.c (PATH_SEPARATOR): Define.
	(set_default_dirlist): Use PATH_SEPARATOR rather than ':'.

> (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.)

 It may make sense to summarise findings from the discussion I referred:
<https://inbox.sourceware.org/gdb-patches/20260629212430.340516-1-pedro@palves.net/>.

  Maciej
  

On Wed, 22 Jul 2026, Jan Dubiec wrote:

> 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

 I think this needs to be complemented with a corresponding update to the 
testsuite, now that a backslash is no longer expected to be there.  Here 
is a list of files affected AFAICT:

ld/testsuite/ld-elf/retain5.map
ld/testsuite/ld-plugin/plugin-10.d
ld/testsuite/ld-plugin/plugin-11.d
ld/testsuite/ld-plugin/plugin-18.d
ld/testsuite/ld-plugin/plugin-19.d
ld/testsuite/ld-plugin/plugin-20.d
ld/testsuite/ld-plugin/plugin-22.d

Would you please try and fix them since you've got the right environment 
to verify such a change?

  Maciej
  

On 25.07.2026 01:30, Jan Dubiec wrote:
> On 24.07.2026 08:48, Jan Beulich wrote:
>> On 22.07.2026 10:42, Jan Dubiec wrote:
>>> This patch is a spin-off of the following discussion:
>>> https://inbox.sourceware.org/binutils/20260717101723.1022175-1-jdx@o2.pl/
>>>
>>> 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.
> 
> Isn't the absence of any regressions sufficient evidence? There's also a 
> simple logical argument: as you noted in another thread, "Clearly, with 
> the many slashes in the paths that you quoted, one more slash won't 
> break things".

My earlier reply looks to have been ambiguous: I was asking for evidence of
ld using slashes. And ...

>> 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 ...
> 
> Sorry, I don't follow. The thread "ld: Skip p33265-2 and pr33265-2 tests 
> on Windows" is about a completely different issue — the MAX_PATH 
> limitation on Windows. The thread "ld: testsuite: Fix a few 
> backslash-related issues on MinGW", on the other hand, deals with 
> problems in three specific test cases caused by incomplete regular 
> expressions. The two issues are completely unrelated.

... I was trying to express that uses in the testsuite aren't a suitable
reference. 

Jan
  

On 26.07.2026 06:23, Maciej W. Rozycki wrote:
> On Wed, 22 Jul 2026, Jan Dubiec wrote:
> 
>> 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
> 
>   I think this needs to be complemented with a corresponding update to the
> testsuite, now that a backslash is no longer expected to be there.  Here
> is a list of files affected AFAICT:
> 
> ld/testsuite/ld-elf/retain5.map
> ld/testsuite/ld-plugin/plugin-10.d
> ld/testsuite/ld-plugin/plugin-11.d
> ld/testsuite/ld-plugin/plugin-18.d
> ld/testsuite/ld-plugin/plugin-19.d
> ld/testsuite/ld-plugin/plugin-20.d
> ld/testsuite/ld-plugin/plugin-22.d
> 
> Would you please try and fix them since you've got the right environment
> to verify such a change?
> 
>    Maciej

It took some time because I had to experiment a bit with 
--enable-plugins and its interactions with other options. At the same 
time, I had to adjust ld/testsuite/config/default.exp to make it 
compatible with Windows.

Anyway, I have modified and tested all of the patches mentioned above, 
and there have been no regressions. I will post the updated patch in a 
new thread shortly.

In another thread, I will also post a preliminary patch for 
ld/testsuite/config/default.exp, as I may have a few questions about it.

/J.D.