[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: make menuconfig deps
From:       Rob Landley <rob () landley ! net>
Date:       2016-07-22 21:44:57
Message-ID: 579293D9.3010404 () landley ! net
[Download RAW message or body]

On 07/22/2016 01:29 PM, David Henderson wrote:
> Hmmm, I'll have to try that next time to see if it works for me.  I'm
> using glibc at the moment since that is what TinyCoreLinux uses (and
> our fork of that OS - XiniX), but long term I have plans to move to
> musl (which is why I asked Rob Landley how his projects were coming).
> That's just more work than I can do at the moment with all the other
> odds and ends of forking.

Since it might be of interest to Denys too (since he uses
http://landley.net/aboriginal toolchains to do the prebuilt busybox
binaries):

My old last gplv2 release of everything toolchain broke 4 times in the
4.4 and 4.5 kernels (arm, mips, sh4, and powerpc all broke in different
ways), so the project's been on hold at the 4.3 kernel for a few months now.

To replace the internal toolchain in aboriginal Linux I'm looking at
moving to clang+llvm (which is in decent shape) and lld.llvm.org (which
isn't). So that's still a ways off.

In the meantime, I'm using Rich Felker's
https://github.com/richfelker/musl-cross-make which uses current
gcc/binutils versions to build musl compilers, and can finally build
_native_ compilers (which is something none of the other toolchain build
projects ever bothered to do). I'm fiddling with the Aboriginal Linux
build so I can use musl-cross-make to replace the simple-cross-compiler
and native-compiler stages, and should write up instructions how to do
that in the next weekend or two.

This means I'm leaving uClibc behind, but given it hasn't had a release
in over 4 years, that's probably for the best. (I'm aware of uclibc-ng
but consider it too little too late.)

It also means I won't be distributing toolchain binaries (I don't do
GPLv3 unless there's a large corporate entity's legal department
standing between me and Bradley/Stallman). But if Rich wants to host
them somewhere in a compatible format I'll happily point to those, and
walk him through the squashfs packaging for the native compilers if he's
interested. So I _should_ still be able to provide native development
environments you don't have to compile yourself if you don't want to. :)

And it means the sparc and m68k targets aren't supported until somebody
ports musl-libc to them. But I should be able to add armv7 and arm64 and
ppc64 and microblaze and get mips64 working again and maybe look into
this "or1k" thing?

Otherwise, I'm still working my way through
http://lists.landley.net/pipermail/toybox-landley.net/2016-June/008484.html
and replacing all the busybox commands used by
http://lists.j-core.org/pipermail/j-core/2016-May/000171.html with
toybox ones, and grinding away at http://landley.net/toybox/roadmap.html
towards 1.0. Plus the
http://j-core.org stuff.

You know, the usual.

Rob
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]