https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
Bug ID: 115189
Summary: libiberty introduces UNC paths waking up binutils bug
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
With gcc 13.2 (and binutils 2.42) located on a mapped network drive on Windows,
it is not possible to build a trivial example below. It worked with gcc 12.3
(and binutils 2.40).
The problem is that a UNC path (\\host\share) is passed to the linker (ld.exe)
instead of the traditional drive letter (D:\directory) via which gcc is
invoked, and the linker cannot deal with it. Reverting
commit e2bb55ec3b70cf45088bb73ba9ca990129328d60
Author: niXman <i.nix...@autistici.org>
Date: Sat Feb 11 06:18:10 2023 +0000
libiberty: fix lrealpath on Windows NTFS symlinks
gcc computes the wrong prefix if invoked through an NTFS
symlink. Try to resolve it if possible.
PR/108350
libiberty/ChangeLog:
* lrealpath.c (lrealpath): try to resolve symlink and
use UNC paths where applicable.
restores the previous behavior (and I am using it as a work-around).
My understanding is (but I've not tested) that this has been fixed in binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=29533
https://sourceware.org/bugzilla/show_bug.cgi?id=31527
However, binutils with that fix haven't been released, yet. It is not
impossible that UNC paths newly produced by gcc would confuse some other tools
coming from the Unix world (though I've not seen it happen, yet).
In principle, I would tend to think that people on Windows use mapped network
drives primarily to avoid UNC paths, as their applications may not work with
them, so, ideally one should respect that and preserve the mapped network
drives in paths. I wonder if it would be possible to defensively amend
libiberty following this principle and hence reduce the amount of bugs it wakes
up in other software.
------------------
# example output from a trivial example
# using Msys2 shell, gcc is on p: mapped from //tsclient/share
env PATH=/p/x86_64-w64-mingw32.static.posix/bin:$PATH g++ -o hw hw.c
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find
//tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/../../../../lib/crt2.o:
Invalid argument
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find
//tsclient/share/x86_64-w64-mingw32.static.posix/bin/../lib/gcc/x86_64-w64-mingw32.static.posix/13.2.0/crtbegin.o:
Invalid argument
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lstdc++: No such
file or directory
P:\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot find -lmingw32: No such
file or directory
...
