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

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

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 <[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.
Sure, go ahead!

/J.D.