-
-
Notifications
You must be signed in to change notification settings - Fork 54
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
Binstall musl
and gnu
builds not compatible due to derived target from build options
#155
Comments
musl
and gnu
builds not compatible due to derived target from build options
Ah, my bad, I completely missed that! |
all good! i haven't had the bandwidth to keep up with all the (great) progress / only thought of it because i've done the armv7/aarch64/gnu/musl dance too many times before ^_^ |
Can we instead detect the target at runtime by invoking |
I don't know if we necessarily want to assume that rustc is available, even though this is a cargo subcommand? |
IMO it is perfectly reasonable to assume the existence of rustc, since cargo-binstall is mostly used in CI environments and they already have rustc installed. For people using it on their own computer, they are extremely likely to also have rustc installed. If rustc is not installed, we can always fallback to the target used in build time. |
Sounds reasonable. Is the information available in a machine-readable format somewhere with rustc or is the format |
There's a nightly cmdline option for machine readable output in
|
Cargo uses this command and parses it internally so we can likely assume it's pretty stable. |
one of my primary goals in starting this was to use on embedded devices without rust installed (which i frequently do), so, would definitely prefer not to depend on this... we could try the host-based detection with a fallback, but, the fallback would still need to resolve the |
That makes sense! A thought: rustup must figure out somehow the platform's target triple to be able to bootstrap/install the first rustc. I'll take a look and see if we can't adapt that for binstall. It's a big bash thing, but we can probably simplify a bit. |
@passcod Take a look at target_lexicon, I found it on lib.rs and might be helpful. |
That just does the same thing as us, it uses the |
There's this, but it doesn't differentiate between musl/gnu at the moment. Might need to fork/patch it. |
Looking at this, it might better to just look for |
Also thinking through, this issue is for musl/gnu but there's actually more issues if we look wider:
So there's both that we want to know the platform of the host at runtime, and also that we may want some flexibility in the fetching logic. |
Maybe we can do the following best-effort detection of target:
To archive the fallback @ryankurte proposed, we can change
And then we can use Using this approach, we don't have to worry too much about our target detection code not working in some nik environment, like non-standard linux filesystem hierarchy and automatically fallback to something that works on all systems (since musl target is statically linked on rust, the binary would likely also statically link other C/C++ libraries and x86_64 binaries work on aarch64-apple-darwin through |
@passcod Actually, we might not need guess_host_triple for linux at all, as we already know most of the information it provides. What we don't know is just Here in For MacOS, however, using guess_host_triple could help us in detecting whether |
hey folks, thanks (particularly @somehowchris, @NobodyXu and @passcod) for all your excellent work on improvements and getting a release out!
the
musl
binaries are a neat addition, but not technically compatible with thegnu
versions because by default we use the target (injected viabuild.rs
) to determine what binaries we'd like to install...i think the best approach to resolving this is probably to trim the
gnu
andmusl
parts of the target and perform a check for both, defaulting to the one that matches out build with user selection if we're running interactively.(also it would be nice to still build the
gnu
binaries, the cursed nightmares related toarmv7
andaarch64
is why we weren't initially using cross, maybe a mix of both approaches would do the trick).i'll try to have a look at it sometime soon but, posting an issue in case one of y'all gets there first ^_^
The text was updated successfully, but these errors were encountered: