dev-lang/rust-bin: add initial ebuild

[stefson]

this is a little ebuild I've been using for a while, it's a copycat
of the rust-bin ebuild from the tree, obviously. It's far from being
perfect, but it's a massive benefit for low end machines.

On top of that, more up to date =dev-lang/rust-1.38.0 is a formidable
bug festival, where cargo build is broken by libgit2 issues.

[blueness]

sorry this fell off the radar. is it good to go?

[stefson]

I'll have to partly rewrite the ebuild, too many changes in recent weeks. I'm going to ping you when it's done.

[gyakovlev]

rust (and rust-bin) 1.41.0 in gentoo will be musl enabled so this is not needed.
eclasses will also support it, namely rust-toolchain eclass, which is currently unable to handle gentoo's CHOST which is *-gentoo-linux-musl, rust simply does not know about this target.

The only problem I see is you HAVE to use -C target-feature=-crt-static in rustflags to compile most of the stuff in with rust-bin on musl, because rust assumes it if target is *-unknown-linux-musl it should do fully static binaries and embed Cruntime in it.

rust (non-bin) will be patched to modify the musl target for gentoo.
I do not plan to do custom *-gentoo-linux-musl targets for rust.

but generally, setting RUSTFLAGS='-C target-feature=-crt-static' in make.conf on musl should make it behave like on glibc systems.

[stefson]

this sounds promissing, please ping me if you need some testing before releasing it into the wild

[gyakovlev]

rust-bin in gentoo now supports musl (amd64 only)
rust(non-bin) also works. if you happen to have working rust installation from smaeul on arm*, you should be able to do system-bootstrap of rust-1.40.0-r1 and keep rolling from there.

don't forget that it emits static binaries by default and you need RUSTFLAGS="-C target-feature=-crt-static" to ask it to do dynamic (make.conf works to set it for portage)

also the rust triple is x86_64-unknown-linux-musl not x86_64-gentoo-linux-musl, as I don't do custom target.

[gyakovlev]

actually it may not work on arm , rust-toolchain.eclass currently does single substring matches with no eabi match, so probably it will match do this armv7a*h*) echo armv7-unknown-linux-gnueabihf;; and it will attempt gnu triple and fail.

[gyakovlev]

it'll need better handling of eabi part to support more musl targets properly.

[stefson]

arm is another story, pulling in sys-libs/libunwind alone is propapbly going to trigger arm specific bugs. I can test on arm in Februrary, hopefully.

[gyakovlev]

libgcc_eh will be ok?

[gyakovlev]

I don't know specifics of rust on arm, what are the problems with libunwind?

[stefson]

I'm glad to test the new version on arm, but please grant me some time to get back with results. arm is slow, and all I'm saying is that using libunwind used to be a problem in the past. Problems as in unable to compile sys-libs/libcxxabi ; so I've always seen it as bit of a fragile package.

[stefson]

It's possible to compile stuff with rust-bin on amd64, I tried with dev-util/cbindgen, but with firefox I'm hitting this on amd64:

rust-lang/cargo#4423 (comment)

[gyakovlev]

as expected. also relevant smaeul/portage-overlay#16
bad news is that we'll need patching either rust or firefox.
good news is that both rust and firefox maintainers are interested in musl support so we'll find a solution ;-)

[stefson]

closing in favour of: #366