Martin Storsjö

> I'll inspect ELF LLD code for `version-script`, probably adapting it for MinGW would be easier (and more time consuming) than using def files. I've looked at it a few...

> So I have solution for BFD: > Add `DATA` to the every symbol other than `__rust*` and `rust*` (there must be better way though). > So the `.def` file...

> `.def` file: > `_ZN113_$LT$std..process..ChildStderr$u20$as$u20$std..sys_common..IntoInner$LT$std..sys..windows..pipe..AnonPipe$GT$$GT$10into_inner17h6a4ea254abb7529eE DATA` > > `$ llvm-nm -A */*std-0ff9e225a311b7d3.dll* | grep 10into_inner17h6a4ea254abb7529eE`: > BFD dll and import library: > > ``` > ld/libstd-0ff9e225a311b7d3.dll.a:d000057.o: 00000000 I __imp__ZN113_$LT$std..process..ChildStderr$u20$as$u20$std..sys_common..IntoInner$LT$std..sys..windows..pipe..AnonPipe$GT$$GT$10into_inner17h6a4ea254abb7529eE >...

> > Does rust generally access them that way even when operating in MSVC mode (where autoimport isn't supported), or why is the dllimport mechanism missing here? > > IIRC...

Ok, so that sounds like the dllimport gets applied correctly, but the dllexport doesn't take effect (maybe an incompatibility between dllexport attributes embedded in the object files vs how ld.bfd...

I'm not sure how to interpret this last error message. So there's an undefined reference against a symbol `__imp__ZN17rustc_error_codes11error_codes11DIAGNOSTICS17h14a72433b55619afE`, and `librustc_driver-eef8b635b20e55e3.dll.a` (a normal import library?) contains that symbol, but `librustc_error_codes-b3fde36a9462d516.rlib`...

> OK it surely is .def parsing issue: > [...] > So `lld-link -safeseh:no -dll -out:foo.dll -entry:main foo.o -implib:libfoo.dll.a -def:lib.def` gives empty symbol but MSVC's `link -safeseh:no -dll -out:foo3.dll -entry:main...

Yes, but it comes at a noticable cost. First off, if you're e.g. on linux and building just a cross compiler, then the compiler itself will be built by your...

> Now that we're using LLVM_LINK_LLVM_DYLIB, wouldn't the build-time cost of LTO be reduced quite a bid? That's quite possible, yes - in theory I guess it should end up...

Out of curiosity, I tried to recreate the benchmark above with the currently pinned version (13.0.0 RC1), and it pretty much confirms the observations above: * ThinLTO is much less...