stefson

I'm sorry, but it still doesn't work with the new patches: ``` 0:05.66 checking whether the C++ compiler supports -Wformat-overflow=2... yes 0:05.68 checking whether the C compiler supports -Wno-gnu-zero-variadic-macro-arguments... no...

If you want to I can send you a copy of my /usr/armv7a-unknown-linux-musleabihf/ rootfs, tared up it's some 250mb. In any case, the problem here is the ambiguity of the...

two things I forgot: you'll need a binary pkg of dev-libs/nss compiled on real harddware (gentoo #699696) - if you don't have that, I can send you one. And I've...

I doubt it's fixed for armv7+neon, but will give it a try nonetheless.

not working with neon instructions, as of today, since it's looking for the gnueabihf thumbv7neon bindings ``` These are the packages that would be merged, in order: [ebuild U #]...

This isn't your overlay, and neither is this your bug. So I'm not sure why you even bother to comment. But if you need to know: there's #684896 for adding...

I tested spidermonkey, which ships the same patchset as firefox, with rust-1.49 it works fine for rust_host `x86_64-gentoo-linux-musl`, but doesn't for `armv7a-unknown-linux-musleabihf` need more time to solve this

the double generated target.armv7(a) in the config.toml might be from an error in the false detection of armv7a-unknown-linux-musleabihf as multilib?

first problem can be solved by unmasking thumb2 mask, and also I believe to have found the line which causes the double entry of armv7+armv7a. Right now the patched up...

thank you so much for pushing the patchset, but tell me where did it end up? Its clearly not merged to the overlay, hence I pulled the commit via `wget...