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

Reply via email to