MinGW: emit dllexport/dllimport by rustc

This fixes various cases where LD could not guess dllexport correctly and greatly improves compatibility with LLD which is not going to support linker scripts anytime soon

1 files changed, 5 insertions, 5 deletions

diff --git a/src/librustc_session/session.rs b/src/librustc_session/session.rs
index fcd5dab94a6..eb6fcb93002 100644
--- a/src/librustc_session/session.rs
+++ b/src/librustc_session/session.rs
@@ -1294,19 +1294,19 @@ pub fn build_session(
 // commandline argument, you can do so here.
 fn validate_commandline_args_with_session_available(sess: &Session) {
     // Since we don't know if code in an rlib will be linked to statically or
-    // dynamically downstream, rustc generates `__imp_` symbols that help the
-    // MSVC linker deal with this lack of knowledge (#27438). Unfortunately,
+    // dynamically downstream, rustc generates `__imp_` symbols that help linkers
+    // on Windows deal with this lack of knowledge (#27438). Unfortunately,
     // these manually generated symbols confuse LLD when it tries to merge
-    // bitcode during ThinLTO. Therefore we disallow dynamic linking on MSVC
+    // bitcode during ThinLTO. Therefore we disallow dynamic linking on Windows
     // when compiling for LLD ThinLTO. This way we can validly just not generate
     // the `dllimport` attributes and `__imp_` symbols in that case.
     if sess.opts.cg.linker_plugin_lto.enabled()
         && sess.opts.cg.prefer_dynamic
-        && sess.target.target.options.is_like_msvc
+        && sess.target.target.options.is_like_windows
     {
         sess.err(
             "Linker plugin based LTO is not supported together with \
-                  `-C prefer-dynamic` when targeting MSVC",
+                  `-C prefer-dynamic` when targeting Windows-like targets",
         );
     }