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 a convention for specifying more paths to toolchain binaries #82

Open
luser opened this issue Jun 22, 2016 · 10 comments
Open

Support a convention for specifying more paths to toolchain binaries #82

luser opened this issue Jun 22, 2016 · 10 comments

Comments

@luser
Copy link

@luser luser commented Jun 22, 2016

Currently cargo supports setting linker and ar in a config file, which is useful but is not always sufficient for cross-compiling crates that build native libraries.

While cross-compiling Servo I found that I had to specify quite a few extra tools to get everything to compile:
https://gist.github.com/luser/a33e5070d1c55a7d2c46fe763a9d1543#file-servo-cross-mac-L59

This was mostly because various crates used different build systems for building native libraries--autotools, cmake, etc. I think it'd be useful if the gcc crate supported a convention for specifying more tools in .cargo/config so that common crates for building native libraries (like cmake) could use that support to drive their builds.

Specifically, I think it would be useful if it allowed at least setting cc, cxx, ranlib, and exposed those values through its API.

@luser
Copy link
Author

@luser luser commented Jun 22, 2016

Interestingly, AFAICT cargo does not expose the values of linker or ar from .cargo/config to build scripts even if they're set.

@alexcrichton
Copy link
Owner

@alexcrichton alexcrichton commented Jun 24, 2016

Yeah currently Cargo doesn't expose linker and/or ar to build scripts, but that probably wouldn't push this over the finish line either as you probably also want to at least read cxx (if not cc before linker). At the very least it'd be good to canonicalize this information all into one location, however, even if Cargo isn't passing the information.

It's probably worth at least doing some parsing of .cargo/config to learn information like this. I'd need to double check to ensure a build script can figure out what directory it was invoked from, however. I forget if that's passed through or not...

@GlenDC
Copy link

@GlenDC GlenDC commented Jul 31, 2016

I'd need to double check to ensure a build script can figure out what directory it was invoked from

That depends on the user. I think you can specify the linker just by giving the name, in case it is in your environment PATH. Personally I don't have it in the path and just gave the full (absolute) location to the file, which would be enough to get the directory, as all the different tools can find in the same directory as the linker.

But even if the user doesn't give the full path, we should be able to get the directory of the executable on all development OS's, no? I know on Unix based systems it's possible with tools like whereis/which, and I suppose Windows has its own system call to get it as well.

@jdub
Copy link
Contributor

@jdub jdub commented Oct 9, 2016

I just noticed that gcc doesn't take advantage of the standard-ish TOOLPREFIX or CROSS_COMPILE environment variables in HOST != TARGET scenarios. Would you accept a change to use these when available?

@alexcrichton
Copy link
Owner

@alexcrichton alexcrichton commented Oct 10, 2016

@jdub certainly! I hadn't heard of those before but if they're commonly in use I'd love to have support for them.

@jdub
Copy link
Contributor

@jdub jdub commented Oct 10, 2016

I might stick to CROSS_COMPILE for now, as it's unclear if TOOLPREFIX and TOOLCHAIN_PREFIX are sufficiently standard-ish. CROSS_COMPILE appears in Linux, musl, etc. as the binary name plus a hyphen, such that you can use it and get a valid binary name even if it's not set, e.g.

CC := $(CCACHE) $(CROSS_COMPILE)gcc
CXX := $(CCACHE) $(CROSS_COMPILE)g++
AR := $(CROSS_COMPILE)ar
@alexcrichton
Copy link
Owner

@alexcrichton alexcrichton commented Oct 10, 2016

Ok sounds good to me!

@pietro
Copy link
Contributor

@pietro pietro commented Jan 23, 2019

FYI, cargo exposes the linker configuration in the RUSTC_LINKER environment variable.

@21oavery
Copy link

@21oavery 21oavery commented Oct 23, 2019

It looks like cargo will pass the environment variable TARGET to build scripts

https://doc.rust-lang.org/cargo/reference/environment-variables.html

Also of note are HOST and NUM_JOBS

@21oavery
Copy link

@21oavery 21oavery commented Oct 23, 2019

And also RUSTC_LINKER, which does what it says

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

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.