Support for musl

[MaxVerevkin]

The issue with musl is that it does not implement dlopen. I don't know how it works with X11, but on wayland, wayland-sys tries to open libwayland-client.so which is not possible.

[maroider]

The issue with musl is that it does not implement dlopen.

Isn't it the case that dlopen works with a dynamically linked musl, but not a statically linked musl?

Either way, I think it's an interesting idea to optionally allow regular (non-dlopen) linking to wayland libs and/or xlib and friends.

[tadeaspaule]

Hi, just a note for anyone having a problem with this, here is how I get around this:

Either run your cargo commands like this:

RUSTFLAGS="-C target-feature=-crt-static" cargo build

Or put this in ~/.cargo/cargo.toml:

[build]
rustflags = ["-C", "target-feature=-crt-static"]

[PureTryOut]

@tadeaspaule

That indeed does the job, thanks! In my case I didn't have this issue with rustc from my distro repositories but I did with the rustup toolchain.

However the ~/.cargo/cargo.toml approach doesn't seem to do the job, my program fails to launch on Wayland again.

[kchibisov]

Winit works with musl for years, though you'd have to do -crt-static as it was said. There're also options to disable dl features on wayland at least.

[lexi-the-cute]

I would like to see support for musl

 alexis@framework  ~/Desktop/catgirl-engine   main  RUST_LOG=catgirl_engine=debug cargo run --target x86_64-unknown-linux-musl --bin catgirl-engine      
   Compiling catgirl-engine v0.5.0 (/home/alexis/Desktop/catgirl-engine)
    Finished dev [unoptimized + debuginfo] target(s) in 2.74s
     Running `target/x86_64-unknown-linux-musl/debug/catgirl-engine`
 DEBUG catgirl_engine > Launched as binary...
 INFO  catgirl_engine::game > Starting Game...
 DEBUG catgirl_engine::game > Setting panic hook...
 DEBUG catgirl_engine::game > Starting Main Loop...
 DEBUG catgirl_engine::client::game_loop > Creating event loop...
 ERROR catgirl_engine::game              > Caught panic: "Could not create an event loop!: NotSupported(NotSupportedError)"

[kchibisov]

what do you mean by that? clearly musl is supported (system install), e.g. alacritty works on alpine for years.

[lexi-the-cute]

what do you mean by that? clearly musl is supported (system install), e.g. alacritty works on alpine for years.

it crashes on trying to open a window when using musl and attempting to use RUSTFLAGS="-C target-feature=-crt-static" just fails to compile due to not finding floorf

[kchibisov]

Do you have a system musl or you want to build a static binary with musl on glibc system? because you'd need to build in sysroot.

[samcday]

I just spent a few hours bashing my head against musl support in wayland-rs, and my conclusion is: it's a mess right now, IMO.

The problem, as I understand it:

1. The default dlopen feature of wayland-sys that is enabled by default in latest versions of winit, will never work with Alpine/postmarketOS, because musl binaries produced by Rust are statically linked, and musl expressly does not support dlopen from statically linked binaries.

2. Disabling the dlopen feature means wayland-sys will attempt to link against system wayland libraries. This means a standard cargo build --target=aarch64-unknown-linux-musl is doomed to failure without a lot of hand-wringing and trial + error setting up a full Alpine sysroot and also manually building and installing wayland-client libs + pkg-config + headers in there. cross also won't work, since their aarch64 musl image is based on Ubuntu, which doesn't have musl libs available for wayland (or for any other libs for that matter).

This issue has been plaguing the Rust community for as long as it has existed. See the countless issues/threads on the interwebz regarding issues building openssl/zlib crates, for example.

The openssl crate has mostly put this issue to bed by providing a crate feature to just build the whole damn thing.

I think wayland-sys needs the same treatment. I'm going to open an issue upstream now.

[kchibisov]

The default dlopen feature of wayland-sys that is enabled by default in latest versions of winit, will never work with Alpine/postmarketOS, because musl binaries produced by Rust are statically linked, and musl expressly does not support dlopen from statically linked binaries.

Yet alacritty is packaged on Alpine for like 4 years using all the said stack with zero patches. Please, use the alpine rust toolchain to build.

This issue has been plaguing the Rust community for as long as it has existed. See the countless issues/threads on the interwebz regarding issues building openssl/zlib crates, for example.

I never had this issue myself since I dynamically link to musl, if you want full static linking it's not what we support.

[samcday]

Yet alacritty is packaged on Alpine for like 4 years using all the said stack with zero patches. Please, use the alpine rust toolchain to build.

Eh, I sorta alluded to this when I mentioned "full Alpine sysroot" above. The thing is, if your host machine is x86-64 and/or not Alpine Linux, then "use the alpine rust toolchain to build." makes for a pretty poor dev experience if you're iteratively building/testing an app for a musl target.

At any rate, my understanding was faulty here. I thought even with RUSTFLAGS="-Ctarget-feature=-crt-static" that dlopen wasn't working.

FWIW, this does work fine for me: RUSTFLAGS="-Ctarget-feature=-crt-static" cross build --target aarch64-unknown-linux-musl --release. So producing a dynamically linked binary targeting musl using the default Ubuntu-based toolchain seems to be fine.

if you want full static linking it's not what we support.

Perhaps that's worth noting somewhere in docs/wiki? Also the requirement that musl targets will only work for dynamically linked binaries (and thus the RUSTFLAGS above are necessary).

I'm happy to contribute some docs somewhere if it's wanted.

[samcday]

I closed the upstream issue as well. Though I still can't help but wonder if a wayland-src crate would be worthwhile, if that's all that would be necessary to produce fully static musl binaries...

[kchibisov]

static linking is generally discouraged and keep in mind that you can't static link on Windows/macOS anyway. Keep in mind that a lots of winit based code deals with hardware linking which requires dlopen because you generally can't static link all existing video drivers.

Also, wayland-rs can be used without system library, but you'll be limited in what you can do and winit doesn't support this mode of operation. Maybe static linking of wayland-rs could make sense, but I don't see why it should be done.

it's just rust has poor musl support in general.

[samcday]

static linking is generally discouraged

Discouraged? By whom? :) I respectfully remind you that Rust statically links binaries by default for musl targets :)

it's just rust has poor musl support in general

This has not been my experience at all. For a tier 2 platform, I've found Rust support for x64 and arm7/8 musl targets to be rock solid. Its the rust ecosystem support that is often not so great.

[kchibisov]

Discouraged? By whom? :) I respectfully remind you that Rust statically links binaries by default for musl targets :)

By all people who could package your software, because if e.g. security vulnerability happens dealing with self-build embeded library is really time consuming for everyone. Also, wayland/x11 stuff updates sometimes and you could benefit from certain fixes, but again you'll miss out on all of them. Just use flatpacks if you want to destribute yourself.

This has not been my experience at all. For a tier 2 platform, I've found Rust support for x64 and arm7/8 musl targets to be rock solid. Its the rust ecosystem support that is often not so great.

Yet they still embed musl during compilation process and force all the distros to patch out musl related stuff, roll their triplets, etc. It gets better, but a lot of distro people still thinks that rust is a bit hostile towards musl dynamic linking, which is default on all distros.

[patrickelectric]

rustflags

I got the following error:

Error relocating /lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found                                                                                                                                                                    
Error relocating /lib/libgcc_s.so.1: __cpu_model: symbol not found                                                                                                                                                                             
Error relocating /lib/libgcc_s.so.1: _dl_find_object: symbol not found                                                                                                                                                                         
Error relocating /lib/libgcc_s.so.1: __memset_chk: symbol not found                                                                                                                                                                            
Error relocating /lib/ld-linux-x86-64.so.2: unsupported relocation type 37                                                                                                                                                                     

It was build using:
CROSS_BUILD_OPTS="--output=type=docker" CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS="-C target-feature=-crt-static" cross build --target=x86_64-unknown-linux-musl --release