[Bug driver/108350] New: Windows: invoking gcc via symlink does not work

[Bug driver/108350] New: Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

            Bug ID: 108350
           Summary: Windows: invoking gcc via symlink does not work
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gnu.org at billz dot fastmail.fm
  Target Milestone: ---

PROBLEM

On Windows if I invoke gcc via a symlink, then it is unable to work. This
appears to happen because it computes the wrong prefix.

The steps to reproduce are:

- Install mingw gcc from https://github.com/niXman/mingw-builds

- Open a powershell prompt.

- Execute: `cmd /c mklink gcc.exe <GCC-INSTALL-PATH>\gcc.exe`. This command
creates a symlink on Windows, which requires Administrator or Developer mode to
be enabled.

- Execute: `ni a.c`. This command creates an empty file `a.c`.

- Execute: `.\gcc.exe a.c`. This command fails with "fatal error: cannot
execute 'cc1': CreateProcess: No such file or directory".

- Execute: `.\gcc.exe -print-search-dirs`. This command prints directories
relative to the location of the symlink, rather than the gcc installation path.

The expected behavior is for `gcc` to work regardless of whether it is invoked
via a symlink or not, because I did not supply the `-no-canonical-prefixes`
option.

This problem was originally reported against the mingw-builds repository, but
investigation showed that the problem is likely with gcc.


INVESTIGATION

Investigation showed that gcc prefixes are handled in `process_command`
(gcc/gcc.cc). When the `-no-canonical-prefixes` option is not supplied prefix
resolution happens in `make_relative_prefix` (libiberty/make-relative-prefix.c)
which calls `lrealpath` (libiberty/lrealpath.c).

On Windows `lrealpath` calls `GetFullPathName` which unfortunately does *not*
do symlink resolution.


FIX

The most straightforward fix is to change `lrealpath` to use
`GetFinalPathNameByHandle` instead of `GetFullPathName`.


For the original issue report and an alternative view of this issue please see
here: https://github.com/niXman/mingw-builds/issues/633

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #1 from niXman <i.nixman at autistici dot org> ---

> FIX
> 
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.

thanks for the investigation!
will do it now.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #2 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #1)
> > The most straightforward fix is to change `lrealpath` to use
> > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
> 
> thanks for the investigation!
> will do it now.

Thank you!

FYI `GetFinalPathNameByHandle` is known to fail on drives that are created via
`DefineDosDevice` (e.g. via the SUBST command). So I recommend using
`GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
fails.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #3 from niXman <i.nixman at autistici dot org> ---
(In reply to Bill Zissimopoulos from comment #2)
> (In reply to niXman from comment #1)
> > > The most straightforward fix is to change `lrealpath` to use
> > > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
> > 
> > thanks for the investigation!
> > will do it now.
> 
> Thank you!
> 
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.

got it, thanks!

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #4 from niXman <i.nixman at autistici dot org> ---

> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.

could you give me a hint, what should I use for `dwFlags` param for
`GetFinalPathNameByHandle()` ? (because for me all the options are
incomprehensible)

because according to your github profile it looks like you are Windows
developer :)

https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea#parameters


thanks!

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #5 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #4)
> > FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> > via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> > `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> > fails.
> 
> could you give me a hint, what should I use for `dwFlags` param for
> `GetFinalPathNameByHandle()` ? (because for me all the options are
> incomprehensible)

I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #6 from niXman <i.nixman at autistici dot org> ---

> I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.

together? OR'ed?

or should I try for the first, and for the second one? or...?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #7 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #6)
> > I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
> 
> together? OR'ed?
> 
> or should I try for the first, and for the second one? or...?

Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.

- `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
resolution.

- `VOLUME_NAME_DOS` is needed to translate the internal NT device name to the
familiar Win32 drives (X:). This may fail with `ERROR_UNRECOGNIZED_VOLUME`
which is why I recommended to use GetFullPathName as a fallback mechanism.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #8 from niXman <i.nixman at autistici dot org> ---

> Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
> 
> - `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
> resolution.
> 
> - `VOLUME_NAME_DOS` is needed to translate the internal NT device name to
> the familiar Win32 drives (X:). This may fail with
> `ERROR_UNRECOGNIZED_VOLUME` which is why I recommended to use
> GetFullPathName as a fallback mechanism.

done, thanks!

in building process... will report.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #9 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Thank you.

Let me know if you need any help from me.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #10 from niXman <i.nixman at autistici dot org> ---

it is strange, but for some reason I can't build master nor 12.2.0 because of
error:
```
{
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/nm
-pg _chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
_subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o gthr-win32_s.o cpuinfo_s.o
sfp-exceptions_s.o _divhc3_s.o _mulhc3_s.o addtf3_s.o divtf3_s.o eqtf2_s.o
getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendhfsf2_s.o extendhfdf2_s.o extendhftf2_s.o extendhfxf2_s.o
extendsfdf2_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfhf2_s.o
truncxfhf2_s.o truncdfhf2_s.o truncsfhf2_s.o trunctfsf2_s.o truncdfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o fixhfti_s.o fixunshfti_s.o floattihf_s.o
floatuntihf_s.o eqhf2_s.o enable-execute-stack_s.o unwind-seh_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o emutls_s.o; echo %%; \
  cat libgcc.map.in; \
} | gawk -f ../../../../../src/gcc-12.2.0/libgcc/mkmap-flat.awk -v
pe_dll=libgcc_s_seh-1.dll > tmp-libgcc.map
mv tmp-libgcc.map libgcc.map
# @multilib_flags@ is still needed because this may use
#
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/xgcc
-B/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include   -fno-checking and -O2
-I../../../../../src/gcc-12.2.0/libgcc/../winsup/w32api/include -g -O2 -pipe
-fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -DIN_GCC
-fPIC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../../../src/gcc-12.2.0/libgcc/../mkinstalldirs .
cp -pR -f libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir ./shlib;
else true; fi &&
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/xgcc
-B/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include   -fno-checking -O2
-I../../../../../src/gcc-12.2.0/libgcc/../winsup/w32api/include -g -O2 -pipe
-fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -DIN_GCC
-fPIC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -shared
-nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o
./shlib/libgcc_s_seh-1.dll.tmp -g -O2 -pipe -fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -B./ 
_chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o
_ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o
__main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o
_ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o gthr-win32_s.o cpuinfo_s.o
sfp-exceptions_s.o _divhc3_s.o _mulhc3_s.o addtf3_s.o divtf3_s.o eqtf2_s.o
getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendhfsf2_s.o extendhfdf2_s.o extendhftf2_s.o extendhfxf2_s.o
extendsfdf2_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfhf2_s.o
truncxfhf2_s.o truncdfhf2_s.o truncsfhf2_s.o trunctfsf2_s.o truncdfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o fixhfti_s.o fixunshfti_s.o floattihf_s.o
floatuntihf_s.o eqhf2_s.o enable-execute-stack_s.o unwind-seh_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a  -lmingwthrd -lmingw32
-lmingwex -lmoldname -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 && if [
-f ./shlib/libgcc_s_seh-1.dll ]; then mv -f ./shlib/libgcc_s_seh-1.dll
./shlib/libgcc_s_seh-1.dll.backup; else true; fi && mv
./shlib/libgcc_s_seh-1.dll.tmp ./shlib/libgcc_s_seh-1.dll && mv
./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
/bin/make install-leaf DESTDIR=../.././gcc \
  slibdir= libsubdir= MULTIOSDIR=.
make[4]: Entering directory
'/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/x86_64-w64-mingw32/libgcc'
__gcc_bcmp.dep:1: *** multiple target patterns.  Stop.

```

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #11 from niXman <i.nixman at autistici dot org> ---
even with a downgraded host toolchain to that which uses mingw-w64 rt-v9 I get
the same error...

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #12 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #10)
> it is strange, but for some reason I can't build master nor 12.2.0 because
> of error:

Unfortunately I am not really familiar with the gcc build process to be of much
help here.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #13 from niXman <i.nixman at autistici dot org> ---
I figured out the building problem.

it seems to work as it should for symlink, but it doesn't work for hardlink.

will dive into docs...

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #14 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #13)
> I figured out the building problem.
> 
> it seems to work as it should for symlink, but it doesn't work for hardlink.

This is good news.

Unless I misunderstand what you mean I think working for symlink, but not
working for hardlink is expected behavior. There is no way to resolve a
hardlink to a "real" path, all hardlinked paths are "real".

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #15 from niXman <i.nixman at autistici dot org> ---

> There is no way to resolve a hardlink to a "real" path, all hardlinked paths are "real".

according to this link:
https://stackoverflow.com/questions/10260676/programmatically-finding-the-target-of-a-windows-hard-link

it seems hardlinks should be resolved too. or I'm wrong?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #16 from niXman <i.nixman at autistici dot org> ---
Created attachment 54264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264&action=edit
patch

the patch for `lrealpath()` for win32.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #17 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #15)
> > There is no way to resolve a hardlink to a "real" path, all hardlinked paths are "real".
> 
> according to this link:
> https://stackoverflow.com/questions/10260676/programmatically-finding-the-
> target-of-a-windows-hard-link
> 
> it seems hardlinks should be resolved too. or I'm wrong?

It is possible on Windows to enumerate all hard links using FindFirstFileNameW
/ FindNextFileNameW. But conceptually at least all hard links are equal to each
other, even if on some file systems a particular hard link is "more equal" than
the others. So IMO hard link resolution makes little sense.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #18 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #16)
> Created attachment 54264 [details]
> patch
> 
> the patch for `lrealpath()` for win32.

Thanks for patch. Looking at it now.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #19 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Comment on attachment 54264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264
patch

Many thanks for the patch. Please consider the following:

LINES 144-152:

I would change the CreateFile call to look like:

    HANDLE fh = CreateFile (
        filename
        ,FILE_READ_ATTRIBUTES
        ,FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
        ,NULL
        ,OPEN_EXISTING
        ,FILE_FLAG_BACKUP_SEMANTICS
        ,NULL
        );

- The FILE_READ_ATTRIBUTES is the only permission required here. (In fact 0
will work as well because CreateFile always adds FILE_READ_ATTRIBUTES.) There
is no need to ask for extra permissions that the process may not have.

- The FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE is something I do
religiously. Although the use of FILE_SHARE_READ should be sufficient in your
case according to documentation, I have found that there are some corner cases
where the use of FILE_SHARE_* flags is not consistent with documentation. To
avoid such cases I use the combo of the flags above.

- The FILE_FLAG_BACKUP_SEMANTICS is needed if lrealpath is used on directories.


LINE 152:

I would fall back to the GetFullPathName method rather than using strdup here.

LINE 192:

There are actually two cases to consider regarding the \\?\ prefix:

- Case \\?\X:\Path\To\File: you should make the conversion \\?\X:\Path\To\File
-> X:\Path\To\File (as you are already doing).

- Case \\?\UNC\Server\Share\Path\To\File: you should make the conversion
\\?\UNC\Server\Share\Path\To\File -> \\Server\Share\Path\To\File

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #20 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Regarding LINE 192:

I would add that if somehow the path returned by GetFinalPathNameByHandle does
not conform to the \\?\X: or \\?\UNC\ pattern I would fall back to
GetFullPathName.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #21 from niXman <i.nixman at autistici dot org> ---
another strange problem is that `CreateFile()` is able to open the special file
`nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full name of
this file and returns 0 and setting `last error` to `ERROR_INVALID_PARAMETER`.

and so you don't get bored I'll add: `GetFullPathName()` can get the full name
of such a file.

(how could this happen? %) )

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #22 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #21)
> another strange problem is that `CreateFile()` is able to open the special
> file `nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full
> name of this file and returns 0 and setting `last error` to
> `ERROR_INVALID_PARAMETER`.
> 
> and so you don't get bored I'll add: `GetFullPathName()` can get the full
> name of such a file.
> 
> (how could this happen? %) )

Yes :)

GetFinalPathNameByHandle internally performs a special request that only file
system drivers respond to (IRP_MJ_QUERY_INFORMATION /
FileNormalizedNameInformation).

So a path like X:\Path\To\File will be resolved to an internal path like:

    \Device\<XVOLDEVICE>\Path\To\File

Now \Device\<XVOLDEVICE> is a file system driver (or points to one via an
elaborate mechanism, but let's not complicate matters further) and knows how to
respond to FileNormalizedNameInformation queries.

OTOH a path like nul will be resolved to an internal path like:

    \Device\Null

This is a simple device and not a file system driver and does not know how to
respond to FileNormalizedNameInformation queries.

So GetFinalPathNameByHandle works on the first, but not the second.

As for GetFullPathName: I think it works by doing simple string manipulations
on the path (i.e. no attempts to open the file and query its path, etc.)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #23 from niXman <i.nixman at autistici dot org> ---
Created attachment 54280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54280&action=edit
patch

looks like I have finished!

boostrapped successfully as x86_64-mingw-w64.


@Bill Zissimopoulos, @Jonathan Wakely 

could you please review the patch?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #24 from niXman <i.nixman at autistici dot org> ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #25 from niXman <i.nixman at autistici dot org> ---
updated patch there:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #26 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #25)
> updated patch there:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html

A couple of things:

1. If the GetFinalPathNameByHandle method fails, I would always fall back to
the GetFullPathName method (which has fewer failure modes).
GetFinalPathNameByHandle can fail for many reasons: for example, if the drive
X: is a local drive created by SUBST/DefineDosDevice or for special files like
NUL (as you have discovered).

2. I would not do anything particular for special files like NUL. See my above
comment: if GetFinalPathNameByHandle fails fall back to GetFullPathName.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #27 from niXman <i.nixman at autistici dot org> ---
ah, got it.
thanks!

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #28 from niXman <i.nixman at autistici dot org> ---
in rebuilding stage...


one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the same
result as before - `fatal error: cannot execute 'cc1': CreateProcess: No such
file or directory`

which way this is usually resolved?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #29 from niXman <i.nixman at autistici dot org> ---
Created attachment 54285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285&action=edit
patch

another version of the patch.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #30 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
> 
> another version of the patch.

Sorry for the delay. Will look at it now.

(In reply to niXman from comment #28)
> one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
> a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the
> same result as before - `fatal error: cannot execute 'cc1': CreateProcess:
> No such file or directory`
> 
> which way this is usually resolved?

Not sure about this one. Are you sure your gcc invocation resulted in finding
your test symlink? In Windows you can do `where.exe gcc` as an equivalent of
`which gcc` on UNIX.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #31 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
> 
> another version of the patch.

Thanks. Your Windows related changes look good to me.

FYI, I am unsure about the need to change all backslashes to slashes and wonder
if this is a backwards incompatible change for users of lrealpath. But I am no
expert in the gcc codebase, so I will let others chime in here.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #32 from niXman <i.nixman at autistici dot org> ---

> Thanks. Your Windows related changes look good to me.

great, thanks!

> FYI, I am unsure about the need to change all backslashes to slashes and
> wonder if this is a backwards incompatible change for users of lrealpath.
> But I am no expert in the gcc codebase, so I will let others chime in here.

the patch that does nothing but replace slashes in paths, I (and not only me)
have been using for ten years - no one complained =)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #33 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Now that we have a potential patch what are the steps to get it included into
the gcc codebase?

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #34 from niXman <i.nixman at autistici dot org> ---
(In reply to Bill Zissimopoulos from comment #33)
> Now that we have a potential patch what are the steps to get it included
> into the gcc codebase?

great question!
I think the best option is to give me rights to merge =)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #35 from niXman <i.nixman at autistici dot org> ---
and the rights to edit my comments too =)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gnu.org at billz dot fastmail.fm]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

--- Comment #36 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #34)
> (In reply to Bill Zissimopoulos from comment #33)
> > Now that we have a potential patch what are the steps to get it included
> > into the gcc codebase?
> 
> great question!
> I think the best option is to give me rights to merge =)

My apologies but I am new to bugzilla and I do not know what that means.

I am looking aroung the bug report user interface and I do not see any obvious
way to give you "rights to merge".

(In reply to niXman from comment #35)
> and the rights to edit my comments too =)

FYI I do not see any obvious way to edit my comments either :)

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[10walls at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

jon_y <10walls at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |10walls at gmail dot com

--- Comment #37 from jon_y <10walls at gmail dot com> ---
Nixman's patch has been committed to master branch as
e2bb55ec3b70cf45088bb73ba9ca990129328d60.

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[gerald at pfeifer dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350

Gerald Pfeifer <gerald at pfeifer dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |gerald at pfeifer dot com

--- Comment #38 from Gerald Pfeifer <gerald at pfeifer dot com> ---
Marking this as RESOLVED FIXED based on the previous comments and 
affirmative reports on gcc-patches@.