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

Profiling builds fail on Linux when linking via rustc #287

Minoru opened this issue Sep 25, 2018 · 2 comments


None yet
2 participants
Copy link

commented Sep 25, 2018

Before the Rust rewrite (#89) can begin in earnest, we have to fit cargo build somewhere in our Makefile and tell the linker how to put it all together.

To that end, I decided to put Rust's main() in front of C++'s main(). Rust won't do anything important here; its role would be to pass argc and argv along to C++, and use the return value as an exit code.

This got implemented and pushed into feature/first-rust-code branch. However, it fails to build on the CI server.

The problems are:

  • GCC 7 and GCC 8 on Linux can't find gcov functions during link stage, even though -l gcov is passed to the compiler;
  • all versions of Clang on Linux fail to find __llvm_gcov* functions. I managed to fix that locally by linking with compiler-rt library, but I don't see a way to do this portably: the library requires a compiler-specific path, and its name includes the architecture name (e.g. libclang_rt.profile-x86_64.a).

I couldn't find any mention of such problems on the Internet, and I'm not sure how to proceed. I think the only reason we do profiling builds at all is to collect test coverage; it's going to become much more complicated with two languages in the mix, so I might just stop doing that for the time of the transition. But if there's an actual solution to this, I'd like to know!

/cc @kpcyrd (because of #286)


This comment has been minimized.

Copy link

commented Sep 26, 2018

In Gecko, we build Rust code into a static lib so that it can be linked with C++ code, and that works well. If you're going to gradually oxidize the codebase, maybe this would be an easier path forward.


This comment has been minimized.

Copy link
Member Author

commented Sep 27, 2018

For whatever reason, I conflated two things: Rust being on the bottom of the call stack, and Rust owning the most long-lived objects in the program. This led me to try to rewrite main first, since that's where long-lived objects are created.

I realize now that these two things are separate. I can make Rust code a library and still put it almost at the bottom of the call stack.

I have a working example in feature/first-rust-code-take-2 branch, and will merge it into master soon. This issue is no longer relevant. Thanks for the insightful comment, @upsuper!

@Minoru Minoru closed this Sep 27, 2018

@Minoru Minoru added this to the 2.14 milestone Dec 29, 2018

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