the status of firefox on musl

[stefson]

recently upstream has anounced some major changes

• cairo-gtk2 will not be supported from >=firefox-53.0 on
• alsa will not be supported anymore (I believe from 52.0-esr on?)

these both seem to be minor problems, gentoo-dev's are aware of it as far as I know.

• dev-lang/rust will be a hard dependency from 54.0 on, according to https://bugzilla.mozilla.org/show_bug.cgi?id=1284816

@lluixhi - any progress in bootstrapping from a musl toolchain? It seems to depend on llvm-4 and clang, and cargo as well? I'd be happy to help out with compile and runtime testing.

[lluixhi]

Yes, the cairo-gtk2 problem is a non-issue, and for users who want to use alsa, apulse is currently fixing issues with firefox, though patched pulseaudio is in the overlay.

I've been watching this issue here: rust-lang/rust#31322
And this is the latest development: rust-lang/rust#40113
It seems like it is not quite ready, but when that PR is merged, we should be able to build a first-class musl version of rust. Hopefully the official rust bootstrap tarballs become statically linked binaries that can dynamically link against musl or glibc, but if not, we need to look into hosting some.

At the moment the only configuration that is possible is a rust toolchain dynamically linked against glibc that statically links binaries against musl.

LLVM is ready, and it looks like cargo also requires a bootstrap binary.

[smaeul]

The PR for rust is fully functioning AFAIK; we're just working out some issues with their CI system. It should be possible to just copy the patches from Alpine at this point. The only two absolutely necessary ones are "musl-support-dynamic-linking.patch", which is just the PR, and "musl-fix-linux_musl_base.patch", which is equivalent to what I've been using locally this whole time (something along those lines will be a second stage of upstreaming). Then we can disable jemalloc with ./configure, or use "musl-fix-jemalloc.patch", which is already upstream.

One thing to watch out for when bootstrapping rust is that you can't just use the installed version, since Gentoo overrides the library directory (adding the version for SLOT support).

It's not likely that rust will provide musl-linked tarballs any time soon (various reasons involving their infrastructure). Right now I have a hacked-up tarball here that could be used to generate something more official.

[stefson]

Any news on this? I would love to test stuff, but this is nothing where I'd be able to just hack myself something which works mostly. If I got it right there is the need of a statical linked rust (or a stage1?) to go ahead with and use for building dynamically linked stage2 which is linked against musl.

Which parts of these are missings? I mean, Alpine seems to have a working binary at least? @smaeul can you please update the link if you happen to have a newer hacked-up tarball at hand?

[smaeul]

@stefson stage0 tarballs are at https://portage.smaeul.xyz/distfiles/. The ones without -dev in the version are the latest stable, with static LLVM, so they should work on any gentoo-musl system. A current ebuild is at https://github.com/smaeul/portage-overlay/tree/master/dev-lang/rust.

[stefson]

Great, thank you so much for making an effort, looks good to me. For easier testing - is there a way to add this via layman?
//Edit: this might be helpfull https://wiki.gentoo.org/wiki/Layman#Adding_custom_repositories

[stefson]

@smaeul - I managed to break the compile, would you like to work on it? If so, should I post it here or over at your own overlay?

[smaeul]

@stefson Post an issue at the overlay please

[stefson]

I just peeked into a beta of firefox 56 and it seems to depend on icu-59.1 if system-icu useflag is activated, but it also seem to depend on llvm and clang.

Mozilla team also announced that it will not continue to support musl on their overlay and patchset until musl-rust hits the tree.

[stefson]

rust-lang/rust#40113 was merged a week ago, this broke static linking for musl which was fixed by rust-lang/rust#44070 - looking pretty good to me :) will the upcoming 1.21 release of rust fully cover musl and therefore be ready for the portage tree?

[stefson]

@smaeul are you willing to offer a statically linked rust-stage for armhf to bootstrap it? If it helps I can offer cpu time to test the compile and runtime.

[smaeul]

@stefson statically-linked rust stage is not possible, because of compiler plugins. (Well, you can create one, but it won't bootstrap.) But I can make a bunch of dynamically-linked-with-rpath stages.

[stefson]

Well, I would really like to try to build firefox for arm with musl, so anything is appreciated that makes this possible. dev-lang/rust-bin and dev-util/cargo would be the minimum I guess, to bootstrap a dev-lang/rust would be cool but is certainly not a must to make it compile.

By the way, do your self-hosted binaries have jemalloc activated?

[stefson]

I forgot to mention something. Since my aim is to build firefox binaries, the correct toolchain needed for rust would be armv7-unknown-linux-gnu if you build against glibc and for I guess it would be armv7-unknown-linux-musl? The first is the only flavour firefox supports for arm, armv6 or earlier is not supported.

[smaeul]

@stefson stage0 binaries for several arches are at https://portage.smaeul.xyz/distfiles/, source for creating them is in the src tarballs, as well as the bootstrap-* branches at https://github.com/smaeul/rust. These should all work with the ebuild in my overlay. I'm pretty much done with rust at this point (been working on the port since January), so if you need more arches or future stage0 tarballs for them, you'll have to try to get this upstream (to something like gentoo/gentoo, gentoo/musl, gentoo/rust, etc.) or do it yourself.

[stefson]

You did a great job on this, highly appreciated! :)

I am very much interested into learning how you did the crosscompiling and bootstrapping part? If you can release documentation about it I might be able to build further stages for arm (nativly) with your stages in the future. Unfortunatley I am not a programmer, so if your efforts regarding the crosscompiling included a lot of hacking around into the source code it is not very likely that I will be capable of maintaining this for a longer period of time.

What is left to do is to adjust the ebuild with arm keywords, which is not that trivial but I might be able to find a solution for it. And open a pullrequest for the overlay if I managed to.

P.S. there is one bigger file without tar.xz in the filelist: cargo-0.21.0-x86_64-unknown-linux-musl