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

Support executable compilation #63

Closed
sfackler opened this issue Dec 8, 2015 · 7 comments
Closed

Support executable compilation #63

sfackler opened this issue Dec 8, 2015 · 7 comments

Comments

@sfackler
Copy link
Member

sfackler commented Dec 8, 2015

A common configuration error when using rust-openssl is to reference headers and libraries from different versions which results in weird and hard to track down breakage. I want to handle this by compiling and running a little executable that compares the values of the version encoded in a #define in the headers and a function in the library.

Unfortunately, gcc-rs will currently only build staticlibs.

@alexcrichton
Copy link
Member

This is actually pretty intentional today because it's not often possible to actually run the executable that would be generated (e.g. almost all cross compilation scenarios).

The "most robust" thing I think would perhaps be something like gcc -E and then parsing the output if you just want to learn about various #define constants.

@sfackler
Copy link
Member Author

sfackler commented Dec 8, 2015

That's a fair point, but the check I want to make isn't necessary for compilation to continue, and since the vast majority of compilation is not crossed I'm fine with gcc-rs saying "no".

The gcc -E approach isn't going to work because I need one #define out of a header and the result of calling SSLeay() at runtime.

@alexcrichton
Copy link
Member

So this is one reason I added the get_compiler API where you could get the tool itself and add your own arguments and such, perhaps that would be good enough for now rather than adding a first-class API?

@AndiDog
Copy link

AndiDog commented Jan 9, 2016

I also just wanted to suggest this feature. If you think cross-compilation is really a problem, you could offer the API to only compile executables to the host architecture (not to the cross-compiled architecture), which is the exact use case of @sfackler and me (dynamic build configuration).

@alexcrichton
Copy link
Member

I'm going to close this as it's not currently my intention to support this in this library as this crate is primarily for build scrips and building native code, especially handling the cross-compile cases.

@quadrupleslap
Copy link

quadrupleslap commented Jan 15, 2018

It's a very niche use-case, but I'm pretty sure generating executables would be very useful for my build script - I need to generate a second executable to be called by the Chromium Embedded Framework on the target platform.

Edit: Also, the get_compiler API @alexcrichton linked above doesn't seem to exist. Was it removed? Nevermind, that link is ancient, it still works.

@quadrupleslap
Copy link

quadrupleslap commented Jan 15, 2018

Does this work across platforms though? I'm not getting any target triples.

let cc = cc::Build::new();
let mut cmd = cc.get_compiler().to_command();
cmd.args(&["-l", "cef", "-o"]);
cmd.arg(out_dir.join("cef-slave"));
cmd.arg("foreign/cef-slave.c");
assert!(cmd.status().unwrap().success());

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants