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

custom_build: add HOST env var #1008

Closed
wants to merge 1 commit into from

Conversation

codyps
Copy link
Contributor

@codyps codyps commented Dec 3, 2014

This is just to support some nice environment aliases in gcc-rs at the moment.

@alexcrichton
Copy link
Member

Perhaps instead of BUILD_KIND a HOST environment variable could be exported? We would define HOST as the host triple of the rust compiler that we're using.

@codyps
Copy link
Contributor Author

codyps commented Dec 4, 2014

I suppose so. I'll end up extracting the same info from that by just doing ${HOST} == ${TARGET} ? "HOST" : "TARGET".

Are you thinking that it might be useful for some build scripts to examine the host?

@codyps
Copy link
Contributor Author

codyps commented Dec 4, 2014

I'd also like to note that testing this plus the cooperating gcc-rs patch seems to result in target rlibs containing host objects (causing the final link to fail). [Strictly, this is better than what happens without these changes, which is build failure in the first user of gcc-rs]

I'm looking at the cargo code to figure out why this is happening, any ideas?

@codyps codyps force-pushed the custom_build_kind branch from ccbbb14 to 41de291 Compare December 4, 2014 04:36
@codyps codyps changed the title custom_build: add BUILD_KIND env var custom_build: add HOST env var Dec 4, 2014
@codyps
Copy link
Contributor Author

codyps commented Dec 4, 2014

I've updated to supply a HOST environment variable.

As an aside: supplying HOST rather than BUILD_KIND also makes bootstrapping a version of cargo with this merged easier, as one can manually set HOST and have it be correct for an entire cargo invocation.

@alexcrichton
Copy link
Member

I was just thinking that it's more in line with TARGET to just say exactly what we're compiling for and you can derive information such as whether it's a cross compile or not from the general information.

I'm not quite sure what's going on with gcc-rs, could you elaborate a little more on that?

bors added a commit that referenced this pull request Dec 4, 2014
This is just to support some nice environment aliases in gcc-rs at the moment.
@codyps
Copy link
Contributor Author

codyps commented Dec 4, 2014

On the issue with cross-compilation and gcc-rs:

Heres a log

Relevant error should be selected, but I'll include it here for clarity:

target/arm-poky-linux-gnueabi/release/deps/libtime-da2a5e65e3acd945.rlib: error adding symbols: File format not recognized

That rlib actually contains a mix of TARGET (elf32 arm) and HOST (elf64 amd64) object files. Here's a readelf -h: https://gist.github.com/jmesmon/d64e0066decd7548f463

It appears that somehow the HOST output of the time crate's build.rs is getting mixed with the TARGET output of the time crate's rust code, which then fails to link.

@bors bors closed this Dec 4, 2014
@alexcrichton
Copy link
Member

That is... surprising! I'd have to take some more time to investigate though.

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

Successfully merging this pull request may close these issues.

3 participants