Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking with LLD #39915

Open
bstrie opened this issue Feb 17, 2017 · 79 comments

Comments

@bstrie
Copy link
Contributor

@bstrie bstrie commented Feb 17, 2017

LLVM 4.0 is shipping with LLD enabled, though AFAIK it is not yet production-ready on all platforms. I believe we've got an LLVM upgrade planned soon to resolve AVR/emscripten problems anyway, so now's the time to start determining what we might need to do to support it, how it impacts compiler performance/binary size/runtime performance compared to our usual linkers, and what platforms on which we might want to enable it by default.

@bstrie bstrie mentioned this issue Feb 17, 2017
3 of 4 tasks complete
@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Feb 17, 2017

See also a PoC in #36120.

@retep998

This comment has been minimized.

Copy link
Member

@retep998 retep998 commented Feb 18, 2017

LLD may be a very good candidate for MinGW targets, because we currently bundle a linker with them anyway and MinGW's linker has a variety of issues ranging from a lack of ASLR to no bigobj support. If we can somehow also bring along the necessary mingw libraries when cross compiling and not just native targeting (which rustup's mingw package is currently limited to), then that would enable rust cross compilation from linux out of the box, which would be a huge improvement over the existing situation where people get MinGW from their distro and then run into issues because distros almost always use an incompatible MinGW.

LLD is not a good candidate for natively targeting MSVC targets, due to several reasons, the primary reason being the lack of debuginfo support. Cross compiling to MSVC targets requires libraries that can't be redistributed so we can't support that out of the box anyway.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Feb 19, 2017

The tracking issue for upgrading to LLVM 4.0 is #37609 .

@binarycrusader

This comment has been minimized.

Copy link
Contributor

@binarycrusader binarycrusader commented Feb 20, 2017

For the record lld is definitely not ready for Solaris targets. But on Solaris, there's no reason that I'm aware of to use lld instead of the native ld instead. We've already been looking at what it would take to have rust use Solaris ld on Solaris instead of using gcc for linking.

@whitequark

This comment has been minimized.

Copy link
Member

@whitequark whitequark commented Feb 20, 2017

@binarycrusader One reason to use lld is when building for Solaris, not on Solaris.

@japaric

This comment has been minimized.

Copy link
Member

@japaric japaric commented Feb 21, 2017

PR #40018 adds a -Z linker-flavor flag to rustc to make it possible to use LLD as a linker. That PR doesn't embed LLD in rustc but allows out of tree experimentation with it.

@binarycrusader ^ that may help with your experiment of directly using Solaris' ld instead of gcc.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Apr 25, 2017

We now appear to be running on LLVM 4.0. @japaric , does this mean that the linker-flavor flag can now be easily used to compare and contrast LLD with the system linker?

@japaric

This comment has been minimized.

Copy link
Member

@japaric japaric commented Apr 29, 2017

@bstrie #40018 landed a few weeks ago. Since that landed one has been able to use -Z linker-flavor=ld -C linker=ld.lld to use an external LLD binary as a linker. Note that, unlike gcc, LLD doesn't know where the system libraries are so you'll have to pass the library search path to the linker using -C link-args='-L ...' if you are linking to any system library.

What LLVM 4.0 helps with is merging LLD into rustc. With that change we wouldn't require an external linker in some scenarios like linking MUSL binaries or bare metal programs. I say some scenarios because most targets require linking to system libraries where you will run into the library search path problem I mentioned above. For those targets, LLD won't work out of the box. It's not clear how and where to solve that problem and without a solution for that we can't switch to LLD for the most important (tier 1) targets, which the reduces the appeal of embedding LLD into rustc in the first place.

@whitequark

This comment has been minimized.

Copy link
Member

@whitequark whitequark commented Apr 29, 2017

@japaric What are the arguments against embedding (sysroot-relative library) search paths, as well as things like -lc -lpthread crt0.o, directly into rustc? After all, some component of the toolchain has to embed them as we don't have any standard for the platforms to follow, and binutils is not a good golden source of this knowledge.

The only drawback I can think of is the situation where the same triple would have different search paths on different flavors of systems (which will likely be exclusive to Linux/glibc triples, and especially bad on platforms with multilib). In that case, I believe clang snoops the OS name and hardcodes OS-specific conventions, which seems bad but probably unavoidable if one wants to distribute a single binary that runs on any Linux (and doesn't need the system linker).

@iainnicol

This comment has been minimized.

Copy link

@iainnicol iainnicol commented Jun 16, 2017

@retep998 I had a brief look at lld a few months ago. I wasn't able to cross compile (cross link?) an .exe from Linux. It seemed like lld only supports platform native formats.

Hopefully I'm mistaken.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Sep 8, 2017

Tagging this as a performance bug, since according to LLD's benchmarks it seems to outperform GNU ld by a factor of ten, and linking performance is a large component of compiler speed currently.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Sep 8, 2017

Er, forgot to link the benchmarks: https://lld.llvm.org/#performance

(Relevant today since LLVM 5.0 has just been released.)

@tpimh

This comment has been minimized.

Copy link

@tpimh tpimh commented Sep 9, 2017

Linking with LLD is much faster than bfd or gold, but I doubt that using it will significantly improve overall performance. Still I think this issue is important and should be a priority.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Sep 9, 2017

@tpimh I'm actually not entirely sure whether the I-slow tag is supposed to represent runtime performance bugs or compiletime performance bugs, I was intending it as the latter. And IME when I look at time-passes output linking is usually in the top three longest phases, significantly longer than most, so even cutting linking time in half would probably be a huge win (especially for big things like Servo and rustc).

@jonas-schievink

This comment has been minimized.

Copy link
Member

@jonas-schievink jonas-schievink commented Sep 9, 2017

@bstrie I-slow is for bad runtime performance, I-compiletime is for compiler perf last time I checked

@iainnicol

This comment has been minimized.

Copy link

@iainnicol iainnicol commented Sep 17, 2017

Good news for anybody interested in the obscure topic of cross linking from Linux to Windows. I said earlier it wasn't possible with lld, but that's only true for lld's ld flavor. It's possible for lld's link.exe flavour (lld-link).

Specifically for Rust we can do this today with a couple code changes.

  1. We need to compile a very small subset of mingw-w64's CRT into .o object files. Namely some thread local storage init. We also need chkstk.

  2. lld does not like MinGW's usual import libraries. Instead we need to build the .def files into .lib files ourselves, using lld-link or llvm-dlltool

  3. Modify lld to treat IMPORT_NAME_NOPREFIX like
    IMPORT_NAME_UNDECORATE, because even with step 2 the .libs aren't perfect

  4. Modify Rust's seh.rs to replace TYPE_INFO_VTABLE with ptr::null(). Required because the symbol ??_7type_info@@6B@ isn't defined in MinGW. Then build and install Rust.

  5. Use .cargo/config to specify a custom wrapper script as the linker.

  6. Our wrapper linker script should invoke lld-link mostly using the parameters it is passed. However we must make a few tweaks:

    a) Fix filename casing e.g. change AdvAPI32.Lib to advapi32.lib

    b) Modify the .def file Rust generates to prefix symbols with an extra underscore

    c) Override the entry point (/entry). Required probably due to a name mangling issue.

    d) Append the mingw-crt object files you compiled in step 1

  7. Build your Rust project using xargo --target=i686-pc-windows-msvc

Doing the above steps allows me to cross compile Rust code. I can even panic and catch panics using Rust's SEH-based unwinding.

@retep998

This comment has been minimized.

Copy link
Member

@retep998 retep998 commented Sep 17, 2017

@iainnicol You're mixing the msvc target with MinGW bits, which is why you have to do all those weird modifications. If you just copy over the libraries from an existing VC++ installation then you can use lld-link normally without all those modifications or any MinGW bits.

@whitequark

This comment has been minimized.

Copy link
Member

@whitequark whitequark commented Sep 17, 2017

But I don't want to use an existing VC++ installation. There isn't even any way to get one without spending something like eight hours downloading and installing junk, much less to redistribute.

@rpjohnst

This comment has been minimized.

Copy link
Contributor

@rpjohnst rpjohnst commented Sep 17, 2017

The standalone build tools are much lighter-weight, unless that's already what you're referring to, in which case perhaps we ought to put some work into improving or recreating what MinGW did so it's actually compatible with MSVC.

@whitequark

This comment has been minimized.

Copy link
Member

@whitequark whitequark commented Sep 17, 2017

The standalone build tools are much lighter-weight

I haven't realized Microsoft distributes those. Could you link to them? Is there any reasonable way to extract the installation archive without actually running it i.e. is it an msi or something similar?

@rpjohnst

This comment has been minimized.

Copy link
Contributor

@rpjohnst rpjohnst commented Sep 17, 2017

Here they are: http://landinghub.visualstudio.com/visual-cpp-build-tools

Both the 2015 and 2017 versions are exes, but you may be able to convince the 2017 exe to give you what you want via this: https://docs.microsoft.com/en-us/visualstudio/install/install-vs-inconsistent-quality-network

@retep998

This comment has been minimized.

Copy link
Member

@retep998 retep998 commented Sep 17, 2017

If we really want to do this right for Windows, we'd first of all need #30027 to eliminate the need for the Windows SDK or MinGW's import libraries. Then all we'd have left is to replace the CRT bits with our own pure Rust versions (math/memory functions, entry point, a few other runtime bits Rust needs) and we'd have a fully self-contained Rust toolchain that can create Windows binaries! The downside of this is that you wouldn't be able to statically link C/C++ code because that relies very heavily on linking in the appropriate CRT from either MinGW or VC++. Of course the whole point of Rust is to rewrite everything in Rust, so this isn't really much of an issue.

@nnethercote

This comment has been minimized.

Copy link
Contributor

@nnethercote nnethercote commented Feb 6, 2019

I haven't heard of the internal linker idea before. I'm not aware of a PR for it.

@mati865

This comment has been minimized.

Copy link
Contributor

@mati865 mati865 commented Feb 6, 2019

#57514 prepared ground for using LLD to link LLVM.

@briansmith

This comment has been minimized.

Copy link

@briansmith briansmith commented Mar 26, 2019

Perhaps initially there should be a middle ground between "default" and "only on nightly," some way of opting into using LLD like we can with -Z, but without using -Z so that it works in stable builds.

#56351 added -C linker-flavor.

It's not clear what this issue is intended to track. It seems like it would be better to close this in favor of having specific issues, e.g. "Link with LLD for -msvc targets when Microsoft's toolchain isn't available".

@nnethercote

This comment has been minimized.

Copy link
Contributor

@nnethercote nnethercote commented Mar 26, 2019

To me, this issue is about enabling LLD as the default linker for all targets. I would like that because LLD is extremely fast, and linking time is often a significant component of compile time, and compile speed is a perennial problem.

@jwatt

This comment has been minimized.

Copy link

@jwatt jwatt commented Mar 26, 2019

FWIW I filed a bug for supporting LLD on macOS over in BMO. Apparently that's WONTFIX. From the comments there it seems that it's not as simple as "LLD is extremely fast", since the LLDs on different platforms are different programs, and the one on macOS is broken with stalled development.

@repi repi mentioned this issue Apr 1, 2019
0 of 1 task complete
@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Apr 3, 2019

Agreed with @briansmith that it would be good to have dedicated issues to track the status of this for different targets, though rather than closing this we could then turn this into a metabug. If there's anyone who knows more about what targets are worth opening issues for, please feel free, since I'm very out of the loop on the LLD support status.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented May 17, 2019

Is linking with LLD documented anywhere? I have (on Linux) rustc -C linker-flavor=ld.lld hello.rs, but I'm not having luck. I thought that LLD was distributed with our copy of LLVM, am I wrong? I've also tried installing LLD via apt, but rustc is still mystified. What are the steps that must be taken to try out LLD with Rust code today?

@phil-opp

This comment has been minimized.

Copy link
Contributor

@phil-opp phil-opp commented May 18, 2019

@bstrie You have to additionally pass the -C linker=rust-lld argument.

@carado

This comment has been minimized.

Copy link

@carado carado commented May 28, 2019

Is it supposed to work with cargo ? I currently get the following errors when trying to build a blank project on the latest nightly build of rust and cargo.

$ RUSTFLAGS='-C linker=rust-lld' cargo build
   Compiling rust3 v0.1.0 (/home/carado/tmp/rust3)
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.2ualxzb8lqn4ho3y.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.32vfyq64cfbzv618.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.4rbt3m5y8o8cl09t.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.ben0932xzwyt64v.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.fzsdnygvstiwzxo.rcgu.o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.x0rq6ifodcf11zi.rcgu.o" "-o" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55" "/home/carado/tmp/rust3/target/debug/deps/rust3-c4f8c40972021c55.1m259ox4uzrzk583.rcgu.o" "--gc-sections" "-pie" "-zrelro" "-znow" "-L" "/home/carado/tmp/rust3/target/debug/deps" "-L" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--start-group" "-Bstatic" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-44988553032616b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-607feef6be9150b2.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-a8dbf6d92401e34a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-9a4716f5e8a3e722.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-988a64d96b043c6d.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-cadd6177b8c6d586.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-8f1d8efc92b45369.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-1e76014677816767.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-cc28bce38cb195d9.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4123e9e89add689a.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4d259c17788c1fb5.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-9495dbda85bb8f16.rlib" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-793d0026c575805f.rlib" "--end-group" "/home/carado/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-33c3162edae6574e.rlib" "-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: rust-lld: error: unable to find library -ldl
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lgcc_s
          rust-lld: error: unable to find library -lc
          rust-lld: error: unable to find library -lm
          rust-lld: error: unable to find library -lrt
          rust-lld: error: unable to find library -lpthread
          rust-lld: error: unable to find library -lutil
          rust-lld: error: unable to find library -lutil
          

error: aborting due to previous error

error: Could not compile `rust3`.

To learn more, run the command again with --verbose.
@almindor

This comment has been minimized.

Copy link

@almindor almindor commented Jul 17, 2019

I'm getting same errors as carado. Managed to "shoehorn" -L /usr/lib into the linker invokation but that just shortens the list of missed libs to -lgcc which does not exist anywhere in the system as libgcc (there's a libgcc_s.a) I suspect this is a result of some gnu-ism but can't figure out how to fix it.

@lnicola

This comment has been minimized.

Copy link
Contributor

@lnicola lnicola commented Jul 24, 2019

@almindor try RUSTFLAGS='-C linker=rust-lld -L /usr/lib -L /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0' or something similar. The path will depend on your distro and compiler version.

@lnicola

This comment has been minimized.

Copy link
Contributor

@lnicola lnicola commented Jul 24, 2019

Is my comment above the right way to use LLD? I can't get it to work, as every program crashes with SIGSEGV:

Reading symbols from target/debug/hello...
(gdb) show directories
Source directories searched: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/etc:$cdir:$cwd
(gdb) r
Starting program: target/debug/hello 

Program received signal SIGSEGV, Segmentation fault.
core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/a7f28678bbf4e16893bb6a718e427504167a9494/src/libcore/ops/function.rs:231
(gdb) l
226	    #[stable(feature = "fn_once_output", since = "1.12.0")]
227	    type Output;
228	
229	    /// Performs the call operation.
230	    #[unstable(feature = "fn_traits", issue = "29625")]
231	    extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
232	}
233	
234	mod impls {
235	    #[stable(feature = "rust1", since = "1.0.0")] 
(gdb) info reg
rax            0x0                 0
rbx            0x0                 0
rcx            0x0                 0
rdx            0x0                 0
rsi            0x0                 0
rdi            0x0                 0
rbp            0x0                 0x0
rsp            0x7fffffffddb0      0x7fffffffddb0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
r13            0x0                 0
r14            0x0                 0
r15            0x0                 0
rip            0x7ffff7ffc000      0x7ffff7ffc000 <core::ops::function::FnOnce::call_once{{vtable-shim}}>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) disassemble 
Dump of assembler code for function core::ops::function::FnOnce::call_once{{vtable-shim}}:
=> 0x00007ffff7ffc000 <+0>:	mov    (%rdi),%rax
   0x00007ffff7ffc003 <+3>:	mov    (%rax),%rdi
   0x00007ffff7ffc006 <+6>:	jmpq   *0x11d4(%rip)        # 0x7ffff7ffd1e0
End of assembler dump.
@lnicola

This comment has been minimized.

Copy link
Contributor

@lnicola lnicola commented Oct 3, 2019

For anyone ending up here, the magic incantation is RUSTFLAGS="-C link-arg=-fuse-ld=lld" cargo build.

@mati865

This comment has been minimized.

Copy link
Contributor

@mati865 mati865 commented Oct 3, 2019

@lnicola note it works only when using GCC 9 or Clang as CC.

@jonhoo

This comment has been minimized.

Copy link
Contributor

@jonhoo jonhoo commented Oct 22, 2019

@bstrie do you know what the current status of this is? What are the blockers to moving forward with it?

@lnicola

This comment has been minimized.

Copy link
Contributor

@lnicola lnicola commented Oct 22, 2019

@mati865 do you happen to know an alternative invocation for people with an older GCC?

@mati865

This comment has been minimized.

Copy link
Contributor

@mati865 mati865 commented Oct 22, 2019

@lnicola all my platforms have Clang + GCC 9 and I haven't investigated how to use it with incompatible compilers.

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Oct 22, 2019

@jonhoo I'm not abreast of any of the work in this area, I suppose you'd want to ask the compiler team.

@jonhoo

This comment has been minimized.

Copy link
Contributor

@jonhoo jonhoo commented Oct 23, 2019

I don't think I can tag teams, and I don't want to cause undue noise for them either. What's the best avenue to get someone from there to take a quick look you think?

@XAMPPRocky

This comment has been minimized.

Copy link
Contributor

@XAMPPRocky XAMPPRocky commented Oct 23, 2019

Triage; @rust-lang/compiler does anyone know what is the current status of this issue?

@bstrie

This comment has been minimized.

Copy link
Contributor Author

@bstrie bstrie commented Oct 25, 2019

For anyone here who manages to get LLD working with Rust, can you additionally include the details about your platform and the specific versions of all compilers being used? I'm still seeing people in the wild having trouble with getting it to work, even with the advice listed here.

@lnicola

This comment has been minimized.

Copy link
Contributor

@lnicola lnicola commented Oct 25, 2019

The command I posted above works on Linux with GCC 9.2.0 and LLD 9.0.0. I think it sometimes also works on Windows, but I've seen someone with a GCC 9 for Windows that did not support -fuse=lld. On MacOS it's not worth trying, according to some links posted here.

@almusil

This comment has been minimized.

Copy link

@almusil almusil commented Oct 30, 2019

For anyone here who manages to get LLD working with Rust, can you additionally include the details about your platform and the specific versions of all compilers being used? I'm still seeing people in the wild having trouble with getting it to work, even with the advice listed here.

cat /etc/system-release
Fedora release 30 (Thirty)

cc --version
cc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)

ld.lld --version
LLD 8.0.0 (compatible with GNU linkers)

Hopefully this helps

@mati865

This comment has been minimized.

Copy link
Contributor

@mati865 mati865 commented Oct 30, 2019

but I've seen someone with a GCC 9 for Windows that did not support -fuse=lld

@lnicola
Windows GCC 9 builds support -fuse-ld=lld (unless they are patched to not support it but why would somebody do it?).
I suppose rust-mingw component was installed and linker was not overridden in .cargo/config. That way rustc picked GCC 6 it ships instead of the system one.

Another issue on Windows is hardcoded linker flag --enable-long-section-names which LLD 9 and older do not support (there are plans to support it in the future). To get around this you can:

  • create wrapper which strips this flag
  • patch LLD to accept this flag as no-op
  • use local patched Rust builds that don't use this flag
@mati865

This comment has been minimized.

Copy link
Contributor

@mati865 mati865 commented Nov 13, 2019

Another issue on Windows is hardcoded linker flag --enable-long-section-names which LLD 9 and older do not support (there are plans to support it in the future).

This part is fixed by: #66257
Windows-gnu users still have to do manual work to use C compiler which supports -fuse-ld=lld though.

@Lokathor

This comment has been minimized.

Copy link
Contributor

@Lokathor Lokathor commented Nov 16, 2019

@bstrie: This works with Stable and Nightly on Windows-MSVC, details in the first post of this gamedev-wg issue: rust-gamedev/wg#50

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.