provide a way of overriding the MinGW library path

[tanriol]

The recently landed #67429 introduced a heuristic to search for the system MinGW libraries relative to the cross-gcc (used as linker) itself. However, there are systems that do not follow this pattern. For example, on my Gentoo system:

• /usr/bin/x86_64-w64-mingw32-gcc is a symlink to /usr/x86_64-pc-linux-gnu/x86_64-w64-mingw32/gcc-bin/9.2.0/x86_64-w64-mingw32-gcc
• /usr/x86_64-w64-mingw32/usr/lib/ is the directory with the actual libraries in the /usr/x86_64-w64-mingw32 sysroot

It would be useful to have a way of overriding the heuristics and informing rustc about the correct library path manually. In the current configuration even RUSTFLAGS="-L /usr/x86_64-w64-mingw32/usr/lib/" does not help because the rustc-provided libraries have higher priority.

[mati865]

cc @alexcrichton
My comment in the PR:

Maybe it'd be possible to reuse one of Cargo configuration fields or add new one to specify path of system libraries.

[alexcrichton]

My hope is that this would be of far lesser urgency than #67429 because this only affects the startup object files which ideally change far less in the gcc toolchain than the rest of the toolchain. The main issue was that we'd prefer our own import libraries and such, which really was only effective if they came from the same toolchain as the host toolchain, which they rarely did.

[mati865]

It'd be nice to have Rust's MinGW follow latest MinGW release but it's not backwards compatible: https://www.diffchecker.com/mjMudsm6
Although it's worth mentioning the last breaking change to the CRT happened 2 years ago. This means using newer MinGW would already increase amount of systems where it just works.

How does *-linux-gnu target work in regard of CRT? It doesn't ship startup objects unlike *-linux-musl and *-windows-gnu targets.

[alexcrichton]

The toolchain used for MinGW has historically been "whatever is on the builders", so it's not strictly kept in sync with something or intentionally held back. It should be updateable at any time!

The non-MinGW targets all rely on the linker to pull in the CRT. None of them work without a preinstalled toolchain, though, whereas one of the purposes of the MinGW toolchain is to work without a preinstalled toolchain.

[mati865]

@alexcrichton there is another case of nonstandard path. 😔
This time on Windows when MinGW is installed through Chocolatey #68872 (comment)

I'll check if it is using symlink which we follow but I'm at a loss.
Chocolatey install wrappers so there is really no way to get location of original executable.

[alexcrichton]

Sorry I don't know of a great way to fix things, I know very little about MinGW myself.

[rivy]

@mati865 , On AppVeyor CI (which uses a choco install of mingw), while testing, I used the relative path "..\lib\mingw\tools\install\mingw64" from the wrapper to the main directory of the install. I believe that should be a relatively stable path. It should be at least testable.

[rivy]

@mati865 ,

After a bit of googling and stackoverflow search, I found a second, more robust, though more complicated/slower, method of finding the installation main directory (ref: SE). Using the --shimgen-noop option to gcc returns a reference to the true installation path (see path to executable).

C:>"c:\ProgramData\chocolatey\bin\gcc.exe" --shimgen-noop
[shim]: Set up Shim to run with the following parameters:
  path to executable: c:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\gcc.exe
  working directory: C:\ProgramData\chocolatey\bin
  is gui? False
  wait for exit? True
  command (optional):
[shim]: Command line '"c:\ProgramData\chocolatey\bin\gcc.exe"  --shimgen-noop'
[shim]: Current process '"c:\ProgramData\chocolatey\bin\gcc.exe"'
[shim]: Command line after removing process '  --shimgen-noop'
[shim]: Arguments after removing shimgen args - ''
[shim]: Arguments are ''

I hope that's helpful.

[mati865]

@rivy Rust could get library path from gcc itself but calling executables on Windows is slow.
I was about to add Chocolatey structure as one of the paths (and fix Cygwin as well) but there was a lot going on for me this week.

[rivy]

@mati865 , yep, I think using the "usual" relative path (ie, "..\lib\mingw\tools\install\mingw64") would be the better choice. I guess you could fall back to parsing the gcc --shimgen-noop output, but that's a lot of effort for a low percentage occurrence.

I do want to say thanks for your efforts on this problem.

[tanriol]

Still, how about a fallback to some config item or environment variable so that it can be made work on unsupported layouts too without rebuilding rustc?