the status of firefox on musl #44

stefson · 2017-04-27T12:08:30Z

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 · 2017-04-28T18:12:56Z

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 · 2017-05-01T05:00:49Z

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 · 2017-08-09T09:52:55Z

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 · 2017-08-09T09:59:55Z

@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 · 2017-08-09T10:32:42Z

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 · 2017-08-09T19:51:53Z

@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 · 2017-08-10T00:32:19Z

@stefson Post an issue at the overlay please

stefson · 2017-08-13T12:49:25Z

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 · 2017-09-02T14:54:38Z

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 · 2017-09-02T14:56:55Z

@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 · 2017-09-02T17:40:25Z

@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 · 2017-09-02T19:15:25Z

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 · 2017-09-08T17:47:28Z

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 · 2017-09-10T17:17:43Z

@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 · 2017-09-10T19:11:51Z

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

stefson · 2017-09-10T19:14:10Z

@doughdemon are you still active with musl on arm?

smaeul · 2017-09-10T19:26:06Z

@stefson Steps for generating a stage0 are:

Download source, either the tarball and patches from the ebuild, or the bootstrap-$VERSION branch from my copy of the repository.
Create config.toml. You can use the one from the ebuild as a base. There is an example in the source tree (src/bootstrap/config.toml.example in older releases).
- Make sure llvm.targets includes your architecture
- Set build.build, build.host, and build.target
- Point build.cargo to your installed cargo, and build.rustc to the same or previous version rustc
- For creating a stage0, make sure build.extended = true and build.openssl-static = true
- Make sure rust.channel = "stable" if you're building a stable version
- For every musl target, ensure target.$TARGET.crt-static = false
- For every cross-compiled target, set target.$TARGET.cc and target.$TARGET.cxx to your cross compiler
Run ./x.py build and ./x.py dist and your output will be in ./build/dist

The cargo without a suffix is a statically-linked cargo for x86_64.

stefson · 2017-09-11T18:06:55Z

checklist for me

Create config.toml. You can use the one from the ebuild as a base. There is an example in the source tree (src/bootstrap/config.toml.example in older releases).
--> the file exists also in current source trees.
Make sure llvm.targets includes your architecture
--> targets = "X86" for amd64 as a host, and ARM if I want to cross compile.
Set build.build, build.host, and build.target
--> I'm not so sure about this. Given that I have a a glibc amd64 system, build and host have to be
build = "x86_64-unknown-linux-gnu"
host = ["x86_64-unknown-linux-musl"]
and if I want to create a stage0 for a musl amd64 system, do I have to append
target = ["x86_64-unknown-linux-musl"]
?
Point build.cargo to your installed cargo, and build.rustc to the same or previous version rustc
--> now I understand what the static cargo binary is good for. You need cargo to build a rust stage0, right?
For creating a stage0, make sure build.extended = true and build.openssl-static = true
extended = true
openssl-static = true
Make sure rust.channel = "stable" if you're building a stable version
channel = "stable"
For every musl target, ensure target.$TARGET.crt-static = false
--> here you lost me. ~~I can't find any option of crt-static. Does that mean it is not mentioned in the example file but it still has to be set?~~ okay, found your patch that introduces this option. But still, in the given case of build stage0 for amd64 musl, what should the value in the config.toml be?
For every cross-compiled target, set target.$TARGET.cc and target.$TARGET.cxx to your cross compiler
--> ~~Do I need a crosscompiler being set up via crossdev?~~ yes, in case of cross compile to armhf the crossdev command would be: TODO hint: gcc toolchain name is armv7a-hardfloat-linux-gnueabi but this fails with stable gcc-5.4.0-r3
--> ~~and therefore edit the option cc = "cc" to what exactly if I am going to cross compile for armv7-hardfloat-linux-musl?~~
The correct values for cross compiling to armv7 are:
cc = "armv7-hardfloat-linux-musl-gcc"
cxx = "armv7-hardfloat-linux-musl-g++"

--enable-llvm-static-stdcpp links libstc++ statically, but how is the option for the config.toml called?

TODO

find out how to build a stage0 for amd64-glibc from amd64-glibc
llvm bootstraped
stage0 std artifacts
stage0 test artifacts
stage0 compiler artifacts
stage0 rustc
openssl for x86_64
stage0 cargo
done, 50m with 4 jobs
./x.py dist
done, 44m with 4 jobs
find out how to build a stage0 for amd64-musl from amd64-glibc
find out how to build a stage0 for armv7-hardfloat-musl from amd64-glibc
crossdev -v -S --gcc 6.4.0 -t armv7a-hardfloat-linux-musleabi

smaeul · 2017-09-12T01:47:19Z

@stefson Why not just use https://portage.smaeul.xyz/distfiles/rust-1.20.0-armv7-unknown-linux-musleabihf.tar.xz ?

But to answer your questions: build, host, and target are interpreted just like they are for gcc. Build is your current system, host is where you want to run the compiled rustc, and target is what platform the newly-compiled rustc can compile for. So to make a rustc that runs on x86_64-unknown-linux-musl and can compile for the same, then put that in both host and target.

Cargo is also included in the stage0. The static version is just for people with mismatched libraries.

You really must have my patches for 1.20.0. It should be exactly like I said: crt-static must be false for every musl target, i.e. every string in the targets array that contains the string "musl"

You need a cross-compiler if and only if you are cross-compiling: if build does not match host. If you are cross-compiling to armv7-hardfloat-linux-musl, then you probably want cc = "armv7-hardfloat-linux-musl-gcc"

stefson · 2017-09-12T15:43:18Z

I tried to avoid installing GCC 6, simply because I don't like to have an unstable toolchain on my system. But after multiple attemps I must say it is way easier to emerge GCC 6 than to mess around with bootstrapping a musl-cross for arm which uses GCC 5 - maybe I'm going to fill a bug for it on bugzilla, maybe not.

To clarify things, I understood you in a way that you are offering these stages but are not going to continue with your efforts providing them - so that someone else must built them from 1.21.0 on?

This is how I understood you, therefore I tried to understand how the cross compile is working to be able to reproduce a new stage 0 , but failing hard with this. The last two bulletpoints in your checklist - can you give me an example what to actually write into the config.toml for

build = "x86_64-unknown-linux-gnu"
host = ["x86_64-unknown-linux-musl"]
target = ["x86_64-unknown-linux-musl"]

and

build = "x86_64-unknown-linux-gnu"
host = ["armv7-unknown-linux-musl"]
target = ["armv7-unknown-linux-musl"]

because I don't understand your explanation about strings and arrays, if I have to replace $TARGET with something from the target defined earlier in the file. Also confused about the different syntax from your posting and the config.toml

P.S. for the first example I would need a crosscompiler too (x86_64-unknown-linux-musl), isn't it?

stefson · 2017-09-17T11:29:35Z

I managed to get a (mostly) working X on the rpi2 with a glibc stage3, firefox 55.0.2 needs a patch to build (taken from fedora) but all I get is a segfault at starting the firefox binary. The ubuntu arm port has a similar issue while the arch linux arm port does not have this issue. Makes me wonder if this is a toolchain bug?

Right now I am trying if 52.3.0esr does give the segfault as well, and later on I might try to build a debug build, which could take a long time to complete.

~~Still not tested the rust-stage0 for musl-arm.~~
rust for musl-arm is up and working :)

lluixhi · 2017-09-20T18:14:39Z

Here's an interesting project:
https://github.com/thepowersgang/mrustc

It appears as though it can bootstrap the rust compiler from just C++, though it only works for x86_64

stefson · 2017-09-24T14:49:51Z

regarding the segfault of firefox-55.0.2 on arm, I read the suggestion that one should deactivate -schedule-insns which is part of the -O2 cflag, which is gentoo standard for firefox on gentoo: --enable-optimization=-O2

this needs to be altered into --enable-optimization=-O2 -fno-schedule-insns (the -fno prefix deactivates the cflag) but I don't understand how to do that? Tried patching the eclass as this:

--- a/mozcoreconf-v5.eclass
+++ b/mozcoreconf-v5.eclass
@@ -162,6 +162,8 @@ mozconfig_init() {
 		mozconfig_annotate "more than -O0 causes a segfault on hppa" --enable-optimize=-O0
 	elif [[ ${ARCH} == x86 ]]; then
 		mozconfig_annotate "less then -O2 causes a segfault on x86" --enable-optimize=-O2
+	elif [[ ${ARCH} == arm ]]; then
+		mozconfig_annotate "full -O2 causes a segfault on arm" --enable-optimize="-O2 -fno-schedule-insns"
 	elif use custom-optimization || [[ ${ARCH} =~ (alpha|ia64) ]]; then
 		# Set optimization level based on CFLAGS
 		if is-flag -O0; then

but portage gets confused by two values for the option, hence shredders the mozconfig with --enable-optimize=-O2 in one line, and -fno-schedule-insns for the next.

As a last ressort only for testing if the segfault goes away with the changed cflag, can I use ebuild $(equery w firefox) configure, edit the mozconfig option about the cflags by hand, and go on by ebuild $(equery w firefox) merge?

smaeul · 2017-09-24T16:13:41Z

@stefson Try something like --enable-optimize="'-O2 -fno-schedule-insns'" (put extra quotes inside the value)

stefson · 2017-09-24T17:41:49Z

The idea is good, but it's not working

If I change the lines to mozconfig_annotate "full -O2 causes a segfault on arm" --enable-optimize="'-O2 -fno-schedule-insns'"

it gives me this during src_configure

Building firefox-55.0.2 with the following configuration
--enable-application=browser mozilla.org default
--enable-optimize='-O2 full -O2 causes a segfault on arm
-fno-schedule-insns' full -O2 causes a segfault on arm

later on complainig

configure: error: These compiler flags for C are invalid: -O2 # full -O2 causes a segfault on arm ac_add_options -fno-schedule-insns

and failing to configure

Can I edit the mozconfig in the WORKDIR by hand, so that I know if this suggestion makes sense at all?

doughdemon · 2017-09-24T19:11:36Z

Have you tried enabling the "custom-cflags" use flag and setting CFLAGS and CXXFLAGS via package.env? This is what I use for firefox-52.2.0 on musl arm.

stefson · 2017-09-24T19:29:51Z

in make.conf I have these cflags
CFLAGS="-O2 -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard"
CXXFLAGS="${CFLAGS}"

and, additionally in package.env, these
MAKEOPTS="-j2"
EXTRA_ECONF="--disable-sandbox --disable-content-sandbox"
CFLAGS="${CFLAGS} -fno-schedule-insns"
CXXFLAGS="${CXXFLAGS} -fno-schedule-insns"

during src_configure you can see that the checks for cflags and so on are going a bit on rampage, adding up many iterations of -fno-schedule-insns on top of each other, but nothing about -O2.

genlop -i firefox shows this

USE=" -bindist -+gmp-autoupdate -hardened -hwaccel -jack -nsplugin -pgo -selinux -test"
CFLAGS="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns CXXFLAGS="-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns -fno-schedule-insns LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags"

No idea what is going on internally in the build system, but this binary segfaults straight away.

I used custom-cfalgs and -optimization flag (overly agressive cflags are getting stripped by the way)

emerge -pv =firefox-55.0.2

These are the packages that would be merged, in order:

[ebuild R *] www-client/firefox-55.0.2::gentoo USE="custom-cflags custom-optimization dbus system-harfbuzz system-icu system-jpeg system-libevent system-sqlite -bindist -debug -gmp-autoupdate (-hardened) -hwaccel -jack -neon -nsplugin (-pgo) -pulseaudio (-selinux) -startup-notification (-system-cairo) -system-libvpx {-test} -wifi" L10N="de -ach -af -an -ar -as -ast -az -bg -bn-BD -bn-IN -br -bs -ca -cak -cs -cy -da -dsb -el -en-GB -en-ZA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mai -mk -ml -mr -ms -nb -nl -nn -or -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -uz -vi -xh -zh-CN -zh-TW" 229.425 KiB

stefson · 2017-10-09T20:47:36Z

In the case of custom-optimization and custom-cflags, the ebuild does not fully honor CFLAGS from make.conf, they have to be set separately via /etc/portage/env and specified explecitly, CFLAGS="${CFLAGS} -fno-schedule-insns" does not work.

For the segfault, I tried all kind of gcc (5.4.0-r3, 6.4.0, 7.1.0) and combinations of CFLAGS (-O2 -fno-schedule-insns, -g -O2 -fno-schedule-insns), to no positive results. So I went back to firefox-esr and am going to wait for further releases to test.

Upstream bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1391802

Uramekus · 2017-12-12T19:02:53Z

Any way we can have rust on-overlay at least?

stefson · 2018-10-11T18:29:13Z

new deps for 63.0 (as of now) will be cbindgen and nodejs

g3ngr33n · 2019-01-01T09:31:32Z

Regarding rust 1.31.1 by smaeul, the firefox ebuild need to be patched

I make a quick and dirty ebuild for testing purpose only

Ebuild :
https://paste.pound-python.org/show/T3IJjQce9XXQWmQFIWGr/

patch to fix the rust target :
https://paste.pound-python.org/show/n54yDln38lta9itdluBM/

Clean patch
https://raw.githubusercontent.com/g3ngr33n/emergeless/master/www-client/firefox/files/rustc-target-musl

g3ngr33n · 2019-01-04T04:03:36Z

I made some test of Firefox 60.4, didn't get any segfault, however on any page loading :

Sandbox: seccomp sandbox violation

On any keyboard input in the url bar this :

JavaScript error: jar:file:///usr/lib/torbrowser/omni.ja!/components/UnifiedComplete.js, line 1004: TypeError: conn is undefined

I get rid of this one by setting browser.urlbar.autocomplete.enabled to false

I won't use firefox after the end of support for the 60.x anyway, nodejs as new dependency is not acceptable for me.

stefson · 2019-03-13T13:26:20Z

If anyone has a memory starving system around, such as rpi, and feels like trying to go for a minimal desktop + X plus one browser - I managed to get a cross compile for firefox-esr working.

How to reproduce:
for the host:

have a cross toolchain installed via crossdev. ~~If you run into errors with cross-musl complainig about cflags, edit and replace the appropiate one temporarily in the hosts make.conf.~~ This got fixed. Going for the same toolchain as the hosts is for sure a good idea.
rust and clang are basically frontends of llvm. Therefore, emerge llvm + clang with synced slots, and rust on top of that. LLVM_TARGETS="ARM" is needed, system-llvm for rust is certainly helpfull as to not mixup too much. patchset for llvm-7.0.1, use it if you're going for system-llvm in dev-lang/rust and not rust-bin.
rust needs the foreign rust-std-${CHOST} installed.
3.1 If you're lucky, then smaeul has a fitting rust-std available. In that case, you can install them by executing install.sh --disable-verify --prefix="/opt/${rust-bin-1*}" --disable-ldconfig
3.2 If you're not so lucky, you'll have to invest a few more cpu cycles and add rust-std suitable for your needs to dev-lang/rust itself. A working example is here: dev-lang/rust: enable rust-std-armv7 as an example stefson/gentoo#6
~~patch cargo.eclass, example for armv7a-glibc is here Cargo cross compile stefson/gentoo#5~~ that patch is needed to cross-compile cbindgen, but since that's only a build time dependency, there's no need to get it going.
spidermonkey is using a faulty autoconf cmd, and this only blows up in cross compile it seems. The official documentation states to issue autoconf-2.13 from within src/js when touching configure files, which is done during patching. see https://bugs.gentoo.org/680210

This patch should fix it:

diff --git a/www-client/firefox/firefox-60.5.2.ebuild b/www-client/firefox/firefox-60.5.2.ebuild
index 91f4a3d..640ccdc 100644
--- a/www-client/firefox/firefox-60.5.2.ebuild
+++ b/www-client/firefox/firefox-60.5.2.ebuild
@@ -209,7 +209,7 @@ src_prepare() {
 
        # Must run autoconf in js/src
        cd "${S}"/js/src || die
-       eautoconf old-configure.in
+       autoconf-2.13
 }
 
 src_configure() {

~~recently introduced llvm checks are a bit of a show stopper. Remove or uncomment them, they are not of any use for cross compile, as they check for llvm in the target and not the host.~~ fixed in tree

emerge with cross-emerge wrappers: emerge-${CHOST} -av firefox

have fun :)

(system-icu and system-sqlite are not working for me)

stefson · 2019-03-13T19:48:36Z

For non-esr, the situation is a bit more complicated. In addition to the aforementioned:

emerge nodejs and cbindgen for the host, update rust + std if needed to.
remove llvm checks, again.
there is a problem with servo/rustbindings. For some reason it decides to go for the hosts compiler instead of the cross-compiler, and this makes rustc panic and the build is busted. Ironically it goes for gcc and not clang. This patch fixes the compile, by setting the value for CC manually:

diff --git a/servo/components/style/build_gecko.rs b/servo/components/style/build_gecko.rs
index 4b5d362..29af2e5 100644
--- a/servo/components/style/build_gecko.rs
+++ b/servo/components/style/build_gecko.rs
@@ -139,7 +139,9 @@ mod bindings {
 
             // Disable rust unions, because we replace some types inside of
             // them.
-            let mut builder = Builder::default().rust_target(RustTarget::Stable_1_0);
+            let mut builder = Builder::default().rust_target(RustTarget::Stable_1_0)
+                .clang_arg("-target")
+                .clang_arg("armv7a-unknown-linux-gnueabihf");
 
             let rustfmt_path = env::var_os("RUSTFMT")
                 // This can be replaced with

be aware, memory footprint has increased seriously, propably through cbindgen. expect ~1,5gb per thread at peak and something around 1,5gb as well for linking with ld.bfd
emerge-${CHOST} -av firefox

enjoy :) and please share with me if you've done some runtime testing.

stefson · 2019-03-21T16:33:44Z

Updated patch for firefox-66. This is for glibc toolchain, replace it with your own value of gcc.

diff --git a/servo/components/style/build_gecko.rs b/servo/components/style/build_gecko.rs
index 734d095..d4ead97 100644
--- a/servo/components/style/build_gecko.rs
+++ b/servo/components/style/build_gecko.rs
@@ -141,7 +141,10 @@ mod bindings {
             // them.
             let mut builder = Builder::default()
                 .rust_target(RustTarget::Stable_1_25)
-                .disable_untagged_union();
+                .disable_untagged_union()
+                .clang_arg("-target")
+                .clang_arg("armv7a-unknown-linux-gnueabihf");
+
 
             let rustfmt_path = env::var_os("RUSTFMT")
                 // This can be replaced with

Sadly it doesn't really work with the musl based rust-std's from smauel yet.

stefson · 2019-05-03T17:20:07Z

anyone got a working sys-libs/compiler-rt-sanitizers ebuild for slot 7 or 8?

//Edit: firefox needs it for elf-hack, despite using gcc as it's main compiler.

Uramekus · 2019-05-03T17:31:51Z

i don't think i got sanitizers working at any point on a musl system.

stefson · 2019-05-03T17:35:37Z

the ebuild from this overlay is working, but it's for slot 6.

anarchpenguin · 2019-05-03T18:20:38Z

my dev overlay

anarchpenguin · 2019-05-03T18:23:44Z

https://gist.github.com/anarchpenguin/36a394950bcfa5a2727ab4f2257a799f sorry I did not add to dev overlay, you can throw patch into /etc/portage/patches/sys-libs/compiler-rt-sanitizers

stefson · 2019-05-03T20:16:56Z

Well, that seems to be the nuclear option. Is it still sufficent to make elf-hack work for firefox?

anarchpenguin · 2019-05-03T21:29:50Z

Well, that seems to be the nuclear option. Is it still sufficent to make elf-hack work for firefox?
yes it will work for you. Really tho elfhack does not require the compiler-rt-sanitizer unless you actually enable llvm

stefson · 2019-06-22T13:29:23Z

I just emerged =firefox-60.7.2 with arm+musl, and it seems some symbols are missing:

ldd /usr/lib/firefox/libxul.so 
	ldd (0x76eb3000)
	liblgpllibs.so => /usr/lib/firefox/liblgpllibs.so (0x76f50000)
	libmozgtk.so => /usr/lib/firefox/libmozgtk.so (0x76f4d000)
	libicui18n.so.64 => /usr/lib/libicui18n.so.64 (0x72d2c000)
	libicuuc.so.64 => /usr/lib/libicuuc.so.64 (0x72ba6000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x72a87000)
	libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x72a75000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x72a46000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x72a33000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x72a20000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x72a01000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x729ec000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x729d3000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0x729bf000)
	libplds4.so => /usr/lib/libplds4.so (0x729ac000)
	libplc4.so => /usr/lib/libplc4.so (0x72998000)
	libnspr4.so => /usr/lib/libnspr4.so (0x72958000)
	libz.so.1 => /lib/libz.so.1 (0x72934000)
	libssl3.so => /usr/lib/libssl3.so (0x728e3000)
	libsmime3.so => /usr/lib/libsmime3.so (0x728b6000)
	libnss3.so => /usr/lib/libnss3.so (0x727b6000)
	libnssutil3.so => /usr/lib/libnssutil3.so (0x72783000)
	libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x72668000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x725c5000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x7257e000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x7253a000)
	libpng16.so.16 => /usr/lib/libpng16.so.16 (0x724fe000)
	libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x724d3000)
	libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x723d5000)
	libhunspell-1.6.so.0 => /usr/lib/libhunspell-1.6.so.0 (0x72366000)
	libevent-2.1.so.6 => /usr/lib/libevent-2.1.so.6 (0x72311000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x72299000)
	libasound.so.2 => /usr/lib/libasound.so.2 (0x721dd000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x72192000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x72164000)
	libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0x7214d000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0x72064000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x7202f000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x71ec4000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x71e69000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x71d5a000)
	libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0x71d47000)
	libXt.so.6 => /usr/lib/libXt.so.6 (0x71ce7000)
	libstdc++.so.6 => /usr/lib/gcc/armv7a-unknown-linux-musleabihf/8.3.0/libstdc++.so.6 (0x71b9e000)
	libgcc_s.so.1 => /usr/lib/gcc/armv7a-unknown-linux-musleabihf/8.3.0/libgcc_s.so.1 (0x71b84000)
	libc.so => ldd (0x76eb3000)
	libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x7157a000)
	libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x714d4000)
	libicudata.so.64 => /usr/lib/libicudata.so.64 (0x6fa81000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x6fa6e000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x6fa59000)
	libbz2.so.1 => /lib/libbz2.so.1 (0x6fa39000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x6f9fd000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x6f9e6000)
	libfribidi.so.0 => /usr/lib/libfribidi.so.0 (0x6f9bb000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x6f9a8000)
	libmount.so.1 => /lib/libmount.so.1 (0x6f949000)
	libpcre.so.1 => /lib/libpcre.so.1 (0x6f8d0000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x6f8b9000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x6f893000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x6f879000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0x6f85b000)
	libatk-bridge-2.0.so.0 => /usr/lib/libatk-bridge-2.0.so.0 (0x6f821000)
	libepoxy.so.0 => /usr/lib/libepoxy.so.0 (0x6f732000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x6f712000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x6f6f9000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x6f6e0000)
	libblkid.so.1 => /lib/libblkid.so.1 (0x6f68b000)
	libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x6f645000)
	libatspi.so.0 => /usr/lib/libatspi.so.0 (0x6f60e000)
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla14SchedulerGroup20sTlsValidatingAccessE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla14SchedulerGroup20sTlsValidatingAccessE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla14AbstractThread17sCurrentThreadTLSE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla14AbstractThread17sCurrentThreadTLSE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla17AutoProfilerLabel12sPseudoStackE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN7mozilla17AutoProfilerLabel12sPseudoStackE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN2js10TlsContextE: symbol not found
Error relocating /usr/lib/firefox/libxul.so: _ZN2js10TlsContextE: symbol not found

the last two could be from spidermonkey, it's a known issue for v60: void-linux/void-packages#2598

Is there a way to understand where these missing symbols are from?

stefson · 2019-06-23T14:02:39Z

Ok, I think I found the reason: since arm is slow and using ld.bfd isn't helpfull with that, I chose to pass --enable-linker=gold; this however doesn't play well with musl when pie is used. So this is essentially a binutils bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23856

anarchpenguin · 2019-07-13T20:54:24Z

68.0 compiles and runs fine. There is a single patch I have not included in the tree or the overlay for rust detection to work properly.

https://github.com/anarchpenguin/portage/blob/master/patches/www-client/firefox/disable_rustc_check.patch

stefson · 2019-07-14T08:50:27Z

Have you tried to emerge v68.0 with USE="lto" enabled? I keep hitting #689358, and with a workaround from the bug I got the same problems with missing symbols.

anarchpenguin · 2019-08-22T03:41:17Z

Have you tried to emerge v68.0 with USE="lto" enabled? I keep hitting #689358, and with a workaround from the bug I got the same problems with missing symbols.

The issue is well known. Upstream along with Gentoo devs are working to find a solution. I have done benchmarks for LTO to non LTO for musl and the gain just isn't enough for me to build with lto useflag enabled.

https://dev.gentoo.org/~anarchy/benchmarks/musl-comparision-libc.txt

If you want to see a full comparision not in diff format just go into benchmark directory they are there still.

anarchpenguin · 2019-08-22T03:42:52Z

www-client/firefox-69.0_beta15::mozilla was built with the following:
USE="custom-cflags custom-optimization dbus hardened hwaccel pulseaudio screenshot system-av1 system-harfbuzz system-icu system-jpeg (system-libevent) system-sqlite system-webp -bindist -clang -debug -eme-free -geckodriver (-gmp-autoupdate) -jack -lto (-neon) -pgo (-selinux) -startup-notification -system-libvpx -test -wayland -wifi" CPU_FLAGS_X86="-avx2"
CFLAGS="-march=native -pipe"
CXXFLAGS="-march=native -pipe -flifetime-dse=1"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags -Wl,-z,relro,-z,now -Wl,--compress-debug-sections=zlib"

That is how firefox is built on this machine with is musl.

12101111 · 2019-10-23T09:59:28Z

I got Segmentation fault when build www-client/firefox-70.0::gentoo
log:

54:16.57 gmake[4]: Entering directory '/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build'
54:16.57 toolkit/library/build/libxul.so
54:16.57 rm -f libxul.so
54:16.57 /usr/lib/llvm/9/bin/x86_64-gentoo-linux-musl-clang++ -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-sized-deallocation -fno-aligned-new -march=skylake -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -funwind-tables  -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so /tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build/libxul_so.list  -flto=thin -lpthread -Wl,-O1 -Wl,--as-needed -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags -Wl,-z,relro,-z,now -Wl,--compress-debug-sections=zlib -fuse-ld=lld -fstack-protector-strong -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,-rpath-link,/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/dist/bin -Wl,-rpath-link,/usr/lib   -fcolor-diagnostics ../../../js/src/build/libjs_static.a /tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/x86_64-gentoo-linux-musl/release/libgkrust.a ../../../security/sandbox/linux/libmozsandbox.so ../../../config/external/lgpllibs/liblgpllibs.so ../../../widget/gtk/mozgtk/stub/libmozgtk_stub.so ../../../widget/gtk/mozwayland/libmozwayland.so -Wl,--version-script,symverscript   -licui18n -licuuc -licudata -laom -lm -lpthread -ldav1d -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -ldl -lc -lffi -lplds4 -lplc4 -lnspr4 -lz -lssl3 -lsmime3 -lnss3 -lnssutil3 -lsqlite3 -lfreetype -lfontconfig -L/usr/lib -lgraphite2 -lharfbuzz -lpng -lwebpdemux -lwebp -levent -lvpx -lpixman-1 -lasound -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lxcb-shm -lpangoft2-1.0 -lXt -lgthread-2.0
54:16.58 clang-9: error: unable to execute command: Segmentation fault
54:16.58 clang-9: error: linker command failed due to signal (use -v to see invocation)
54:16.58 gmake[4]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/rules.mk:661: libxul.so] Error 254
54:16.58 gmake[4]: Leaving directory '/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build'
54:16.58 gmake[3]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/recurse.mk:74: toolkit/library/build/target] Error 2
54:16.58 gmake[2]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/recurse.mk:34: compile] Error 2
54:16.58 gmake[1]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/rules.mk:391: default] Error 2
54:16.58 gmake: *** [client.mk:125: build] Error 2
54:16.60 115 compiler warnings present.

USE flags:

clang cpu_flags_x86_avx2 custom-cflags custom-optimization hardened hwaccel lto screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libvpx system-sqlite system-webp wayland

anarchpenguin · 2019-10-23T10:19:40Z

I got Segmentation fault when build www-client/firefox-70.0::gentoo
log:

54:16.57 gmake[4]: Entering directory '/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build'
54:16.57 toolkit/library/build/libxul.so
54:16.57 rm -f libxul.so
54:16.57 /usr/lib/llvm/9/bin/x86_64-gentoo-linux-musl-clang++ -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-error=tautological-type-limit-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-sized-deallocation -fno-aligned-new -march=skylake -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -O2 -fomit-frame-pointer -funwind-tables  -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so /tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build/libxul_so.list  -flto=thin -lpthread -Wl,-O1 -Wl,--as-needed -Wl,-rpath=/usr/lib/firefox,--enable-new-dtags -Wl,-z,relro,-z,now -Wl,--compress-debug-sections=zlib -fuse-ld=lld -fstack-protector-strong -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,-rpath-link,/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/dist/bin -Wl,-rpath-link,/usr/lib   -fcolor-diagnostics ../../../js/src/build/libjs_static.a /tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/x86_64-gentoo-linux-musl/release/libgkrust.a ../../../security/sandbox/linux/libmozsandbox.so ../../../config/external/lgpllibs/liblgpllibs.so ../../../widget/gtk/mozgtk/stub/libmozgtk_stub.so ../../../widget/gtk/mozwayland/libmozwayland.so -Wl,--version-script,symverscript   -licui18n -licuuc -licudata -laom -lm -lpthread -ldav1d -lrt -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -ldl -lc -lffi -lplds4 -lplc4 -lnspr4 -lz -lssl3 -lsmime3 -lnss3 -lnssutil3 -lsqlite3 -lfreetype -lfontconfig -L/usr/lib -lgraphite2 -lharfbuzz -lpng -lwebpdemux -lwebp -levent -lvpx -lpixman-1 -lasound -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lxcb-shm -lpangoft2-1.0 -lXt -lgthread-2.0
54:16.58 clang-9: error: unable to execute command: Segmentation fault
54:16.58 clang-9: error: linker command failed due to signal (use -v to see invocation)
54:16.58 gmake[4]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/rules.mk:661: libxul.so] Error 254
54:16.58 gmake[4]: Leaving directory '/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/ff/toolkit/library/build'
54:16.58 gmake[3]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/recurse.mk:74: toolkit/library/build/target] Error 2
54:16.58 gmake[2]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/recurse.mk:34: compile] Error 2
54:16.58 gmake[1]: *** [/tmp/portage/www-client/firefox-70.0/work/firefox-70.0/config/rules.mk:391: default] Error 2
54:16.58 gmake: *** [client.mk:125: build] Error 2
54:16.60 115 compiler warnings present.

USE flags:

clang cpu_flags_x86_avx2 custom-cflags custom-optimization hardened hwaccel lto screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libvpx system-sqlite system-webp wayland

Disable lto useflag which is known to cause an OOM, I will mask the useflag for mozilla packages via the profile shortly.

stefson · 2019-11-19T21:40:52Z

--enable-elfhack is broken on arm for firefox-68.2.0, again

stefson · 2019-11-22T08:30:02Z

For armv7: the build system has a bug, where there's some sort of race condition in python2 mach --build at the end of the build process, eating a whole core for hours. Canceling the emerge, and resuming with ebuild $(equery w firefox) merge does result in a working binary. Going once for quickpkg firefox and emerge -avK firefox solves the problem entirely.

I don't have a clue how to even try to debug this.

But runtime testing went fine. If anyone is interested into the binary, I can send it over.

stefson · 2019-12-13T20:41:47Z

how to use clang with cross compile:

drop this as a wrapper into /usr/lib/llvm/x/bin/ and name it accordingly, firefox expects ${CHOST}-clang, and make it executeable with chmod +x


#!/bin/bash

SYSROOT="/usr/armv7a-unknown-linux-gnueabihf"
TARGET="armv7a-linux-gnueabihf"
COMPILER_PATH="${SYSROOT}/usr/armv7a-unknown-linux-gnueabihf/gcc-bin/9.2.0/"

exec env COMPILER_PATH="${COMPILER_PATH}" \
	clang --target=${TARGET} \
		--sysroot="${SYSROOT}" \
		-isysroot "${SYSROOT}" \
		-L"${COMPILER_PATH}" \
		"$@"

modelled by this example:
https://blog.meinside.dev/Build-Cross-Compile-Tools-for-Raspberry-Pi-on-macOS/

the wrapper passes the whole src_configure, so I'm going to call it a day and share it with you.

anarchpenguin · 2020-01-21T14:59:45Z

Support is done on the forums. Please open a bug on bugzilla or a new ticket if you find a bug that is effecting musl.

stefson · 2020-01-28T13:36:17Z

This used to be a place to chat and seek support on a lower level than bugzilla. Really I don't understand why you've decided to put an end to it.

anarchpenguin · 2020-01-28T14:07:58Z

This used to be a place to chat and seek support on a lower level than bugzilla. Really I don't understand why you've decided to put an end to it.
Low end user support is done via forums, not the development repository. If you find a true issue for mozilla projects on musl open a new ticket, it makes it easier for people to find if they are having the same issue. It also means users do not need to spend extensive time reading threw to see if their issue has been reported.

stefson mentioned this issue Sep 15, 2017

How to compile rust in a musl libc based linux system rust-lang/rust#31322

Closed

liqa mentioned this issue Jul 12, 2019

WIP: testing/firefox: upgrade to 68.0 alpinelinux/aports#9373

Closed

PureTryOut mentioned this issue Sep 20, 2019

Firefox password fields broken by multiprocess setting void-linux/void-packages#12885

Closed

anarchpenguin closed this as completed Jan 21, 2020

the status of firefox on musl #44

the status of firefox on musl #44

Comments

stefson commented Apr 27, 2017 • edited Loading

lluixhi commented Apr 28, 2017

smaeul commented May 1, 2017

stefson commented Aug 9, 2017

smaeul commented Aug 9, 2017

stefson commented Aug 9, 2017 • edited Loading

stefson commented Aug 9, 2017

smaeul commented Aug 10, 2017

stefson commented Aug 13, 2017

stefson commented Sep 2, 2017

stefson commented Sep 2, 2017

smaeul commented Sep 2, 2017

stefson commented Sep 2, 2017

stefson commented Sep 8, 2017

smaeul commented Sep 10, 2017

stefson commented Sep 10, 2017

stefson commented Sep 10, 2017

smaeul commented Sep 10, 2017

stefson commented Sep 11, 2017 • edited Loading

smaeul commented Sep 12, 2017 • edited Loading

stefson commented Sep 12, 2017 • edited Loading

stefson commented Sep 17, 2017 • edited Loading

lluixhi commented Sep 20, 2017

stefson commented Sep 24, 2017

smaeul commented Sep 24, 2017

stefson commented Sep 24, 2017 • edited Loading

doughdemon commented Sep 24, 2017 via email

stefson commented Sep 24, 2017

stefson commented Oct 9, 2017

Uramekus commented Dec 12, 2017

stefson commented Oct 11, 2018

g3ngr33n commented Jan 1, 2019 • edited Loading

g3ngr33n commented Jan 4, 2019

stefson commented Mar 13, 2019 • edited Loading

stefson commented Mar 13, 2019

stefson commented Mar 21, 2019

stefson commented May 3, 2019 • edited Loading

Uramekus commented May 3, 2019

stefson commented May 3, 2019 • edited Loading

anarchpenguin commented May 3, 2019

anarchpenguin commented May 3, 2019

stefson commented May 3, 2019

anarchpenguin commented May 3, 2019

stefson commented Jun 22, 2019

stefson commented Jun 23, 2019

anarchpenguin commented Jul 13, 2019

stefson commented Jul 14, 2019

anarchpenguin commented Aug 22, 2019

anarchpenguin commented Aug 22, 2019

12101111 commented Oct 23, 2019

anarchpenguin commented Oct 23, 2019

stefson commented Nov 19, 2019

stefson commented Nov 22, 2019 • edited Loading

stefson commented Dec 13, 2019

anarchpenguin commented Jan 21, 2020

stefson commented Jan 28, 2020

anarchpenguin commented Jan 28, 2020

stefson commented Apr 27, 2017 •

edited

Loading

stefson commented Aug 9, 2017 •

edited

Loading

stefson commented Sep 11, 2017 •

edited

Loading

smaeul commented Sep 12, 2017 •

edited

Loading

stefson commented Sep 12, 2017 •

edited

Loading

stefson commented Sep 17, 2017 •

edited

Loading

stefson commented Sep 24, 2017 •

edited

Loading

g3ngr33n commented Jan 1, 2019 •

edited

Loading

stefson commented Mar 13, 2019 •

edited

Loading

stefson commented May 3, 2019 •

edited

Loading

stefson commented May 3, 2019 •

edited

Loading

stefson commented Nov 22, 2019 •

edited

Loading