@@ -620,6 +620,39 @@ impl<'a> Builder<'a> {
620
620
// Set this for all builds to make sure doc builds also get it.
621
621
cargo. env ( "CFG_RELEASE_CHANNEL" , & self . build . config . channel ) ;
622
622
623
+ // This one's a bit tricky. As of the time of this writing the compiler
624
+ // links to the `winapi` crate on crates.io. This crate provides raw
625
+ // bindings to Windows system functions, sort of like libc does for
626
+ // Unix. This crate also, however, provides "import libraries" for the
627
+ // MinGW targets. There's an import library per dll in the windows
628
+ // distribution which is what's linked to. These custom import libraries
629
+ // are used because the winapi crate can reference Windows functions not
630
+ // present in the MinGW import libraries.
631
+ //
632
+ // For example MinGW may ship libdbghelp.a, but it may not have
633
+ // references to all the functions in the dbghelp dll. Instead the
634
+ // custom import library for dbghelp in the winapi crates has all this
635
+ // information.
636
+ //
637
+ // Unfortunately for us though the import libraries are linked by
638
+ // default via `-ldylib=winapi_foo`. That is, they're linked with the
639
+ // `dylib` type with a `winapi_` prefix (so the winapi ones don't
640
+ // conflict with the system MinGW ones). This consequently means that
641
+ // the binaries we ship of things like rustc_trans (aka the rustc_trans
642
+ // DLL) when linked against *again*, for example with procedural macros
643
+ // or plugins, will trigger the propagation logic of `-ldylib`, passing
644
+ // `-lwinapi_foo` to the linker again. This isn't actually available in
645
+ // our distribution, however, so the link fails.
646
+ //
647
+ // To solve this problem we tell winapi to not use its bundled import
648
+ // libraries. This means that it will link to the system MinGW import
649
+ // libraries by default, and the `-ldylib=foo` directives will still get
650
+ // passed to the final linker, but they'll look like `-lfoo` which can
651
+ // be resolved because MinGW has the import library. The downside is we
652
+ // don't get newer functions from Windows, but we don't use any of them
653
+ // anyway.
654
+ cargo. env ( "WINAPI_NO_BUNDLED_LIBRARIES" , "1" ) ;
655
+
623
656
if self . is_very_verbose ( ) {
624
657
cargo. arg ( "-v" ) ;
625
658
}
0 commit comments