Implement unstable -Clink-self-contained values for MCP 510

[lqd]

This PR is extracted from #96401 for easier review.

It implements half of MCP #510 as a prerequisite for supporting rust-lld via a command similar to -Clinker-flavor=gcc:lld -Clink-self-contained=linker: adding new unstable values to the -Clink-self-contained to independently control:

• the CRT object linking, and
• using the rustup-distributed linker

r? @petrochenkov

I know you plan on switching this to a +/- list: I didn't do this yet so this PR still represents the rough interface that was described in the zulip thread for opting in and out of both facets. And so still has temporary work, until we finalize the interface we want, and I'll make the changes you'd like to see in this PR.

[bors]

☔ The latest upstream changes (presumably #97239) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

What we are currently shipping together with Rust toolchains.

windows-gnu:
	//MinGW libs
	"libgcc.a",
	"libgcc_eh.a",
	"libgcc_s.a",
	"libm.a",
	"libmingw32.a",
	"libmingwex.a",
	"libstdc++.a",
	"libiconv.a",
	"libmoldname.a",
	"libpthread.a",

	//Windows import libs
	"libadvapi32.a",
	"libbcrypt.a",
	"libcomctl32.a",
	"libcomdlg32.a",
	"libcredui.a",
	"libcrypt32.a",
	"libdbghelp.a",
	"libgdi32.a",
	"libimagehlp.a",
	"libiphlpapi.a",
	"libkernel32.a",
	"libmsimg32.a",
	"libmsvcrt.a",
	"libodbc32.a",
	"libole32.a",
	"liboleaut32.a",
	"libopengl32.a",
	"libpsapi.a",
	"librpcrt4.a",
	"libsecur32.a",
	"libsetupapi.a",
	"libshell32.a",
	"libsynchronization.a",
	"libuser32.a",
	"libuserenv.a",
	"libuuid.a",
	"libwinhttp.a",
	"libwinmm.a",
	"libwinspool.a",
	"libws2_32.a",
	"libwsock32.a",

	// Linker and dlltool
	"(i686,x86_64)-w64-mingw32-gcc.exe"
	"ld.exe"
	"dlltool.exe"
	"libwinpthread-1.dll" // needed by the exes

	// Crt objects
	"crt2.o", "dllcrt2.o"
musl:
	"libc.a"
	"crt1.o", "Scrt1.o", "rcrt1.o", "crti.o", "crtn.o", "crtbegin.o", "crtbeginS.o", "crtend.o", "crtendS.o"
	"libunwind.a"
wasi:
	"libc.a"
	"crt1-command.o", "crt1-reactor.o"
fuchsia, fortanix, gnullvm (do not go through the self-contained dir but should):
	"libunwind.a"
other:
	sanitizer libs

[petrochenkov]

These files can be pretty clearly separated into multiple components:

• linker
• crt objects
• libc
• libgcc/libunwind
• sanitizers
• rest of the mingw stuff

Notes:

• dlltool goes together with linker, and will hopefully be reimplemented in Rust one day, using object-rs or whatever is necessary
• libm, libpthread are a part of libc, they exist as separate libs only on some platforms, a couple more of mingw libs may also go there, need to investigate
• I suspect that many of libs shipped with windows-gnu target are not even necessary for libstd, they were just used in the past to build rustc in self-contained mode

Relevant GCC/Clang options (for naming considerations):

• crt objects: -nostartfiles
• libc: -nolibc
• libgcc/libunwind: -shared-libgcc, -static-libgcc, -unwindlib=<arg>

[petrochenkov]

My suggested naming for the components: linker, crto, libc, unwind, sanitizers, mingw.

-Clink-self-contained=yes is -Clink-self-contained=+linker,+crto,+libc,+unwind,+sanitizers,+mingw.
-Clink-self-contained=no is -Clink-self-contained=-linker,-crto,-libc,-unwind,-sanitizers,-mingw.
-Clink-self-contained=+/-component only enables/disables that component, other components keep their default values (which may differ depending on targets).
+/-component does nothing if it's irrelevent to the given target.

Alternative: more coarse-grained components - +/-tools for linker and dlltool, and +/-libs for everything else.

[petrochenkov]

Multiple -Clink-self-contained options can be accumulated like -Ctarget-features.
E.g. -Clink-self-contained=yes -Clink-self-contained=-linker will mean -Clink-self-contained=-linker,+crto,+libc,+unwind,+sanitizers,+mingw.

This way we should be able to implement or stabilize all these components one by one, I think.

[mati865]

dlltool goes together with linker

Seems reasonable given the fact the same Binutils bug that prevents us from using LLD also forces us to use dlltool.

will hopefully be reimplemented in Rust one day, using object-rs or whatever is necessary

I'd rather hope Binutils one day lands a fix for their bug with short import libs so windows-gnu can replace it (and the linker) with the same solution as windows-msvc and windows-gnullvm use.

[bors]

☔ The latest upstream changes (presumably #98975) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC]

@lqd any updates on this?

[Dylan-DPC]

Closing this pr due to inactivity