Invoking gcc via symlink does not work

[billziss-gh]

Problem

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

Steps to reproduce

• Create a symlink to the installed gcc:

  billziss@xps ⟩ ~\t ⟩ cmd /c mklink gcc.exe C:\Users\billziss\AppData\Local\mingw64\bin\gcc.exe
  symbolic link created for gcc.exe <<===>> C:\Users\billziss\AppData\Local\mingw64\bin\gcc.exe

• Create an empty file a.c:

  billziss@xps ⟩ ~\t ⟩ ni a.c
  
      Directory: C:\Users\billziss\t
  
  Mode                 LastWriteTime         Length Name
  ----                 -------------         ------ ----
  -a----          1/7/2023  10:41 PM              0 a.c
  

• Attempt to build a.c via the symlink:

  billziss@xps ⟩ ~\t ⟩ .\gcc.exe a.c
  gcc.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
  compilation terminated.

• Print the search directories via the symlink. The reported paths are relative to the symlink and incorrect:

  billziss@xps ⟩ ~\t ⟩ .\gcc.exe -print-search-dirs
  install: C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/
  programs: =C:/Users/billziss/t/../libexec/gcc/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/t/../libexec/gcc/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/
  libraries: =C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/t/../lib/gcc/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../lib/;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/x86_64-w64-mingw32/12.2.0/;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/../lib/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/;C:/Users/billziss/t/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/

• Attempt to build a.c directly via the gcc found in the PATH (this fails because a.c is an empty file, but a compilation is attempted):

  billziss@xps ⟩ ~\t ⟩ gcc.exe a.c
  C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain'
  collect2.exe: error: ld returned 1 exit status

• Print the search directories directly via the gcc found in the PATH. The reported paths are relative to the real location of gcc and correct:

  billziss@xps ⟩ ~\t ⟩ gcc.exe -print-search-dirs
  install: C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/
  programs: =C:/Users/billziss/AppData/Local/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/AppData/Local/mingw64/bin/../libexec/gcc/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/
  libraries: =C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../x86_64-w64-mingw32/12.2.0/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../lib/;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/x86_64-w64-mingw32/12.2.0/;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/../lib/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/;C:/Users/billziss/AppData/Local/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../;C:/buildroot/x86_64-1220-win32-seh-rt_v10-rev1/mingw64/mingw/lib/

Expected behavior

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

• For example, on Linux:

  billziss@xps ⟩ ~/t $ ln -s /usr/bin/gcc gcc
  billziss@xps ⟩ ~/t $ touch a.c
  billziss@xps ⟩ ~/t $ ./gcc a.c
  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
  (.text+0x24): undefined reference to `main'
  collect2: error: ld returned 1 exit status
  billziss@xps ⟩ ~/t $ ./gcc -print-search-dirs
  install: /usr/lib/gcc/x86_64-linux-gnu/9/
  programs: =/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/
  libraries: =/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/9/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/9/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/

Environment

• gcc version:

  gcc.exe (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 12.2.0

[niXman]

thanks for the report!

will try to deal with this...

[niXman]

it looks like the issue happens because the GCC driver doesnt check gcc.exe for hardlink and because of that it doesnt follow the hardlink...

[niXman]

the mklink without /h doesnt want to create anything with error message like insufficient privileges.

with /h option I can create the hard link and confirm the issue.

[billziss-gh]

Thank you for looking into this:

The mklink command works to create symbolic links in two cases:

• From an administrator prompt.
• By enabling developer mode (see https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/). I recommend this method.

with /h option I can create the hard link and confirm the issue.

Actually if gcc.exe is accessed via a hard link the behavior described in this issue should be considered correct (IMO), because gcc cannot resolve the hard link and find the "real" path it points to (there is no readlink for hard links). It is only when gcc.exe is accessed via a symbolic link that the behavior described in this issue should be considered incorrect (IMO).

---

When I first reported this issue I did a bit of investigation and found out that gcc appears to handle prefixes in process_command:

• If the -no-canonical-prefixes option is set, then it resolves prefixes using make_relative_prefix_ignore_links (without considering symbolic links).
• Otherwise (i.e. in the normal case) it resolves prefixes using make_relative_prefix.

I do not know if something in the mingw gcc build process forces the -no-canonical-prefixes option.

The code for make_relative_prefix is here. It uses lrealpath, which on Windows uses GetFullPathName, which should work.

I have not had the chance to run this under a debugger yet (as I would have to rebuild gcc with debug info, etc.), but I suspect that a debugging session around these functions would be very illuminating.

[billziss-gh]

I setup a build of GCC with debug symbols and ran it under GDB. Indeed make_relative_prefix, lrealpath and GetFullPathName were called as expected.

Turns out that I had a thinko when I said: "on Windows uses GetFullPathName, which should work". GetFullPathName did not resolve the symbolic link during my debugging session and indeed the GetFullPathName documentation makes no mention of symbolic link resolution.

The correct API to use is GetFinalPathNameByHandle.

In any case this is not a problem of the mingw-builds project but rather a problem of the upstream gcc project. I will have to report it to them and possibly provide a patch.

[niXman]

Thank you @billziss-gh , it would be great!

[billziss-gh]

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

[niXman]

thank you!

[niXman]

Actually if gcc.exe is accessed via a hard link the behavior described in this issue should be considered correct (IMO)

just to be sure: as I reported on bugzilla, I have fixed the behavior for symlinks, but it still doesn't work correctly for hardlinks.

or im wrong?

@billziss-gh

[billziss-gh]

Sorry for the late response. For some reason email notifications from the bugzilla do not seem to work for me, even though I think I have them enabled in my mail preferences.

[niXman]

as example:

[billziss-gh]

Thank you. The behavior is same as in Linux:

billziss@xps ⟩ /home/billziss/t $ touch a.c
billziss@xps ⟩ /home/billziss/t $ ln -s /usr/bin/x86_64-linux-gnu-gcc-9 sgcc
billziss@xps ⟩ /home/billziss/t $ ln /usr/bin/x86_64-linux-gnu-gcc-9 hgcc
billziss@xps ⟩ /home/billziss/t $ ./sgcc a.c
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status
billziss@xps ⟩ /home/billziss/t $ ./hgcc a.c
hgcc: fatal error: cannot execute ‘cc1’: execvp: No such file or directory
compilation terminated.

The soft linked sgcc is able to find its prefix and the hard linked hgcc is not:

billziss@xps ⟩ /home/billziss/t $ ./sgcc -print-search-dirs
install: /usr/lib/gcc/x86_64-linux-gnu/9/
programs: =/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/9/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/9/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
billziss@xps ⟩ /home/billziss/t $ ./hgcc -print-search-dirs
install: /home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/
programs: =/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/:/home/billziss/t/../lib/gcc/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/9/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/bin/
libraries: =/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/:/home/billziss/t/../lib/gcc/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/9/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/../lib/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/9/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/9/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/9/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/lib/:/home/billziss/t/../lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/

[niXman]

the hard linked hgcc is not

so, should I try to deal which this? is the direction specified at the link correct?

[billziss-gh]

so, should I try to deal which this?

In my opinion, no, you should not need to do anything about the hard link.

[niXman]

then OK, will publish the patch!

[billziss-gh]

then OK, will publish the patch!

Please see some of my comments in bugzilla about the patch.

[niXman]

yeah, I see. I fix it.

[niXman]

@billziss-gh

could you look at the updated patch please?: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350#c29

[billziss-gh]

I am closing this as it will be addressed in GCC 13. Thanks again for your patch.