Re: gcc segfault at src/mman/mlockall.c

[Isaac Dunham <idunham@lavabit.com>]

On Fri, 18 May 2012 18:58:45 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> > On Fri, May 18, 2012 at 08:43:33PM +0200, Jens Staal wrote:
> > > > obase-musl still lacks a lot due to many legacy syscalls musl
> > > > probably won't implement.
> > > >
> > > Could libbsd help with those?
..
> There's really no cost to adding syscall
> wrappers. If it's a matter of library functions though, then yes, I'd
> agree. If using obase is desirable, it would be best to patch out the
> non-portable stuff in obase, or if that's too difficult, use libbsd
> (hopefully an improved version; in its current form, it seems very
> broken and like gnulib has a lot of #error in the #else cases).
I ought to try compiling libbsd again...
 
> By the way, sbase in its current form is not much of an option. As far
> as I can tell, the only way its tools "suck less" is in the area of
> bloat; in the area of actually working correctly, they leave A LOT to
> be desired. For example, at a first glance, grep lacks support for
> multiple regexes (either on the command line with -e or
> newline-separated, or from a file with -f). This kind of
> non-conformance will badly break all sorts of shell scripts, including
> possibly configure scripts (thus making it impossible to build any
> software).
> 
> There is also my noXCUse package, which aims at complete conformance
> in all commands implemented, but not many commands are implemented
> yet.
Had not heard of that one, and Google seems not to recognize it... Is it
publicly available yet?

While we're enumerating permissively-licensed userspaces, we might as
well remember Android's toolbox, and more relevantly toybox (Landley's
project that set off the whole discussion of licensing).
And in the less-viable set of options, there's beastiebox (way too
limited and BSD-specific, though it may compile on Linux),
and somewhere I saw a git repo with a port of netbsd userspace to
uclibc (incompatible with musl, of course--uclibc seems to be the most
"legacy friendly" libc in terms of headers, even compared with glibc).
Besides that there's heirloom-tools.
That would make 8 packages under permissive licenses that aim at what
you're talking about.
So it isn't like there's a lack of options, it's just that none of
them seem to be ready at present.
By the way, make is probably one of the biggest limitations--Linux and
musl both rely extensively on gmake features that none of the
BSD/permissively-licensd make versions support yet.  You probably won't
get the kernel policy changed, either.

Isaac Dunham