Skip to content
This repository has been archived by the owner on Aug 31, 2023. It is now read-only.

musl / alpine linux support #3633

Open
1 task done
lholden opened this issue Nov 10, 2022 · 9 comments
Open
1 task done

musl / alpine linux support #3633

lholden opened this issue Nov 10, 2022 · 9 comments
Assignees
Labels
S-Bug: confirmed Status: report has been confirmed as a valid bug

Comments

@lholden
Copy link

lholden commented Nov 10, 2022

Environment information

Unfortunately, I can't run the `rome rage` command due to the issue in question.

Using docker image `node:16-alpine`, which uses alpine / musl.

What happened?

Tried to run rome on our CI pipeline, only to discover the binary isn't able to run in the node:16-alpine image we are using for this.

Most likely due to it using musl instead of glibc.

Expected result

rome to work on my CI pipeline ;)

Specifically, I think it would make sense if musl targets got added as a release artifacts, and for those to be pulled down instead of linux-x86.

Code of Conduct

  • I agree to follow Rome's Code of Conduct
@lholden lholden added the S-To triage Status: user report of a possible bug that needs to be triaged label Nov 10, 2022
@sebmck
Copy link
Contributor

sebmck commented Nov 10, 2022

Likely the same issue as #3549.

@lholden
Copy link
Author

lholden commented Nov 10, 2022

Seems like the other issue was related to the binary depending on a newer version of glibc than what was shipped in CentOS, where this is specifically a problem where musl (glibc replacement) is used.

So... might be the same issue, or at least, having the same solution? For example, statically linking to all glibc libs might solve both issues.

I wasn't really sure if it would make sense to contribute to that issue or create a new one :)

@MichaReiser
Copy link
Contributor

The two are related but require slightly different solutions

Supporting musl requires a separate Rome build for every platform that links against musl instead of glibc. Musl is a Tier 2 target of Rusttier 2

@ematipico ematipico added S-Bug: confirmed Status: report has been confirmed as a valid bug and removed S-To triage Status: user report of a possible bug that needs to be triaged labels Nov 16, 2022
@ematipico ematipico moved this to Todo in Rome 2022 Nov 16, 2022
@MichaReiser MichaReiser removed this from Rome 2022 Nov 30, 2022
@Conaclos
Copy link
Contributor

With gcompat I encountered an error with pico-args that I reported. It could be nice to see if we got new problems once #4405 merged.

@pacak
Copy link

pacak commented May 14, 2023

It could be nice to see if we got new problems once #4405 merged.

I'm curious as well. I've confirmed that basic examples x86_64-unknown-linux-musl works as expected, maybe gcompat is doing something fishy when there's no arguments.

@Conaclos how do I run anything with alpine/gcompat?

@Conaclos
Copy link
Contributor

@pacak You just need to install gcompat:

apk add gcompat

@pacak
Copy link

pacak commented May 14, 2023

I'm on Ubuntu so it won't work :) Any ready made docker script that I can hack or anything like that?

@Conaclos
Copy link
Contributor

Ah sorry I tested on q fresh installation. I did not test with a container...

@pacak
Copy link

pacak commented May 15, 2023

Well, FWIW cargo-show-asm I downloaded with cargo-binstall works in docker with alpine linux and gcompat installed but I imagine it was compiled for musl specific target. cargo-show-asm should be using bpaf 0.8. A few examples I compiled myself with --target x86_64-unknown-linux-musl worked fine as well. I couldn't get native glibc examples compiled on my machine to run - fails with strange linker errors.

rome I downloaded from the releases pages failed to run without libgcc and once I installed that it failed to get any command line arguments from std::env::args_os(). So something breaks std::env::args_os() and std::env::args() that uses it.

A simple replication - this should print something like ArgsOs { inner: ["target/debug/foo"] }.

fn main() {
    println!("{:?}", std::env::args_os());
}

There's not much I can do to support it, but compiling for musl target specifically should work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
S-Bug: confirmed Status: report has been confirmed as a valid bug
Projects
None yet
Development

No branches or pull requests

7 participants