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

GNU toolchain on Windows can't build compiler plugins since nightly 2017-12-15. #47029

Closed
Rantanen opened this issue Dec 27, 2017 · 4 comments
Closed
Labels
A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows

Comments

@Rantanen
Copy link
Contributor

PS C:\Dev\Projects\rust-plugin-test\src> rustup run nightly-2017-12-15-gnu rustc --version
rustc 1.24.0-nightly (0077d128d 2017-12-14)

lib.rs

#![feature(rustc_private)]
extern crate rustc_plugin;

Building the above file as a dylib (or alternatively using cargo and plugin = true) fails:

PS C:\Dev\Projects\rust-plugin-test\src> rustup run nightly-2017-12-15-gnu rustc lib.rs --crat
e-type dylib
error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" ... // continues...
  = note: ld: cannot find -ldbghelp

The full error can be seen on AppVeyor for example:

https://ci.appveyor.com/project/Rantanen/intercom/build/129/job/0k9k54hkwk1f0sfw

The build works just fine on the previous nightly.

PS C:\Dev\Projects\rust-plugin-test\src> rustup run nightly-2017-12-14-gnu rustc --version
rustc 1.24.0-nightly (f8af59d95 2017-12-13)
PS C:\Dev\Projects\rust-plugin-test\src> rustup run nightly-2017-12-14-gnu rustc lib.rs --crat
e-type dylib

As far as I can tell, dbghelp is an MSVC dependency and should be omitted for the GNU toolchain.

@Rantanen
Copy link
Contributor Author

I suspect the issue is a result of ea35192, which added backtrace as a dependency to the rustc package. backtrace again depends on dbghelp-sys, which causes the linking issue I believe.

The standard library seems to use dbghelp through a dlopen instead of compile time linking:

pub fn unwind_backtrace(frames: &mut [Frame])
-> io::Result<(usize, BacktraceContext)>
{
let dbghelp = DynamicLibrary::open("dbghelp.dll")?;
// Fetch the symbols necessary from dbghelp.dll
let SymInitialize = sym!(dbghelp, "SymInitialize", SymInitializeFn)?;
let SymCleanup = sym!(dbghelp, "SymCleanup", SymCleanupFn)?;
let StackWalk64 = sym!(dbghelp, "StackWalk64", StackWalk64Fn)?;

Wouldn't this approach work for backtrace-rs as well?

@retep998
Copy link
Member

dbghelp-sys bundles libdbghelp.a so depending on it normally works. However when the precompiled version is distributed inside rustc internal crates, libdbghelp.a is not brought along, causing stuff to fail to link. The simplest solution on Rust's side is to simply add libdbghelp.a to the set of mingw import libraries that it bundles.

@mati865
Copy link
Contributor

mati865 commented Dec 27, 2019

Presumably fixed by #47280.
@Rantanen could you confirm?

@Rantanen
Copy link
Contributor Author

Rantanen commented Dec 27, 2019

Compiler plugins are now deprecated so this works even less now with the whole rustc_plugin being unavailable. I'm sure there's some way to get these working, but given the deprecation, I've got no motivation to figure that out. :)

(I'm encountering a compilation issue before linking. I don't think this is anything GNU-toolchain specific at the moment.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows
Projects
None yet
Development

No branches or pull requests

4 participants