* gcc segfault at src/mman/mlockall.c @ 2012-05-15 16:35 Isaac Dunham 2012-05-15 16:42 ` Isaac Dunham 0 siblings, 1 reply; 18+ messages in thread From: Isaac Dunham @ 2012-05-15 16:35 UTC (permalink / raw) To: musl With -Os -fno-stack-protector, gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3 gcc -std=c99 -nostdinc -ffreestanding -ffloat-store -frounding-math -D_XOPEN_SOURCE=700 -I./src/internal -I./include -I./arch/i386 -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 -march=i486 -mtune=generic -Os -fno-stack-protector -c -o src/mman/mlockall.o src/mman/mlockall.c cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. make: *** [src/mman/mlockall.o] Error 1 gcc=latest gcc-4.4 package from Ubuntu With -O3, I get === gcc -std=c99 -nostdinc -ffreestanding -ffloat-store -frounding-math -D_XOPEN_SOURCE=700 -I./src/internal -I./include -I./arch/i386 -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer -falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 -march=i486 -mtune=generic -O3 -fno-stack-protector -c -o src/misc/getgrouplist.o src/misc/getgrouplist.c cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. make: *** [src/misc/getgrouplist.o] Error 1 === Switching over to gcc-4.1, since I've used that without errors. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-15 16:35 gcc segfault at src/mman/mlockall.c Isaac Dunham @ 2012-05-15 16:42 ` Isaac Dunham 2012-05-15 19:21 ` Szabolcs Nagy 0 siblings, 1 reply; 18+ messages in thread From: Isaac Dunham @ 2012-05-15 16:42 UTC (permalink / raw) To: musl On Tue, 15 May 2012 09:35:53 -0700 Isaac Dunham <idunham@lavabit.com> wrote: [using gcc-4.4, the standard with Ubuntu 10.04, segfaults] > Switching over to gcc-4.1, since I've used that without errors. gcc-4.1 works. By the way, would there be an option to change the gcc version used by musl-gcc? (ie, use gcc=gcc-4.1) Isaac Dunham ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-15 16:42 ` Isaac Dunham @ 2012-05-15 19:21 ` Szabolcs Nagy 2012-05-15 19:30 ` Szabolcs Nagy 0 siblings, 1 reply; 18+ messages in thread From: Szabolcs Nagy @ 2012-05-15 19:21 UTC (permalink / raw) To: musl * Isaac Dunham <idunham@lavabit.com> [2012-05-15 09:42:36 -0700]: > By the way, would there be an option to change the gcc version used by > musl-gcc? (ie, use gcc=gcc-4.1) > maybe -V worksm try musl-gcc -V 4.1 --version vs musl-gcc -V 4.4 --version ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-15 19:21 ` Szabolcs Nagy @ 2012-05-15 19:30 ` Szabolcs Nagy 2012-05-16 18:53 ` Isaac Dunham 0 siblings, 1 reply; 18+ messages in thread From: Szabolcs Nagy @ 2012-05-15 19:30 UTC (permalink / raw) To: musl * Szabolcs Nagy <nsz@port70.net> [2012-05-15 21:21:04 +0200]: > maybe -V worksm try > musl-gcc -V 4.1 --version i could try it meanwhile, it works but --version does not :) so you can use CC='musl-gcc -V 4.1' ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-15 19:30 ` Szabolcs Nagy @ 2012-05-16 18:53 ` Isaac Dunham 2012-05-16 22:04 ` Szabolcs Nagy 0 siblings, 1 reply; 18+ messages in thread From: Isaac Dunham @ 2012-05-16 18:53 UTC (permalink / raw) To: musl On Tue, 15 May 2012 21:30:53 +0200 Szabolcs Nagy <nsz@port70.net> wrote: > * Szabolcs Nagy <nsz@port70.net> [2012-05-15 21:21:04 +0200]: > > maybe -V worksm try > > musl-gcc -V 4.1 --version > > i could try it meanwhile, it works but --version does not :) > so you can use > CC='musl-gcc -V 4.1' same situation here but when you just told it the version to use, why ask? By the way, would you have pointers on using pcc with musl? Is it possible to use it as a glibc -> musl cross-compiler ? ..seems that the official "cross-compiler" method might work for that...if binutils doesn't pose a problem. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-16 18:53 ` Isaac Dunham @ 2012-05-16 22:04 ` Szabolcs Nagy 2012-05-17 6:07 ` Isaac Dunham 2012-05-18 14:58 ` Jens Staal 0 siblings, 2 replies; 18+ messages in thread From: Szabolcs Nagy @ 2012-05-16 22:04 UTC (permalink / raw) To: musl * Isaac Dunham <idunham@lavabit.com> [2012-05-16 11:53:41 -0700]: > On Tue, 15 May 2012 21:30:53 +0200 > > i could try it meanwhile, it works but --version does not :) > > so you can use > > CC='musl-gcc -V 4.1' > same situation here > but when you just told it the version to use, why ask? just to see if -V really worked :) > By the way, would you have pointers on using pcc with musl? > Is it possible to use it as a glibc -> musl cross-compiler ? > ..seems that the official "cross-compiler" method might work for > that...if binutils doesn't pose a problem. i'm not sure what is a glibc->musl cross-compiler i used something like the following to compile with pcc using musl libc MUSL=/path/to/musl PCC=`pcc -v foobar.o 2>&1 |sed -n 's,.* \([^ ]*\)/lib/crtbegin.o.*,\1,p'` x.o: x.c pcc $(CFLAGS) -nostdinc -isystem $(MUSL)/include -isystem $(PCC)/include -c -o $@ $< x-static1: x.o ld -X -d -e _start -Bstatic -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc x-static2: x.o pcc -static -nostdlib -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc x-dynamic1: x.o ld -X -d -e _start -dynamic-linker /lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc x-dynamic2: x.o pcc -nostdlib -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc if you want to compile musl itself with pcc iirc you only have to change -lgcc into -lpcc in the Makefile ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-16 22:04 ` Szabolcs Nagy @ 2012-05-17 6:07 ` Isaac Dunham 2012-05-18 14:58 ` Jens Staal 1 sibling, 0 replies; 18+ messages in thread From: Isaac Dunham @ 2012-05-17 6:07 UTC (permalink / raw) To: musl On Thu, 17 May 2012 00:04:57 +0200 Szabolcs Nagy <nsz@port70.net> wrote: > i'm not sure what is a glibc->musl cross-compiler Built on glibc, targets musl (similar to musl-gcc, though a strict cross-compiler is a little more complex) > i used something like the following to compile with pcc using musl > libc > MUSL=/path/to/musl > PCC=`pcc -v foobar.o 2>&1 |sed -n 's,.* > \([^ ]*\)/lib/crtbegin.o.*,\1,p'` > > x.o: x.c > pcc $(CFLAGS) -nostdinc -isystem $(MUSL)/include -isystem > $(PCC)/include -c -o $@ $< x-static1: x.o > ld -X -d -e _start -Bstatic -o $@ $< $(LDFLAGS) > $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o > $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib > -lpcc x-static2: x.o pcc -static -nostdlib -o $@ $< $(LDFLAGS) > $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o > $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib > -lpcc x-dynamic1: x.o ld -X -d -e _start > -dynamic-linker /lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) > $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o > $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib > -lpcc x-dynamic2: x.o pcc -nostdlib > -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) > $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o > $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib > -lpcc For static, I can do it about like so (shell): # Pass 1: headers pcc $@ -nostdinc -isystem $MUSL/include -isystem $PCC/include # Pass 2: linking executables STARTOBJ="$MUSL/lib/crti.o $MUSL/lib/crt1.o $PCC/lib/crtbegin.o" ENDOBJ="$PCC/lib/crtend.o $MUSL/lib/crtn.o -L$MUSL/lib -lc -L$PCC/lib \ -lpcc" pcc -nostdlib -static $STARTOBJ $@ $ENDOBJ Thanks! Isaac Dunham ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-16 22:04 ` Szabolcs Nagy 2012-05-17 6:07 ` Isaac Dunham @ 2012-05-18 14:58 ` Jens Staal 2012-05-18 17:21 ` Christian Neukirchen 1 sibling, 1 reply; 18+ messages in thread From: Jens Staal @ 2012-05-18 14:58 UTC (permalink / raw) To: musl 2012/5/17 Szabolcs Nagy <nsz@port70.net>: > if you want to compile musl itself with pcc > iirc you only have to change -lgcc into -lpcc > in the Makefile > Very cool, so with obase-musl [1] and pcc self-hosting on musl, we would only need the BSDfund challenge [2] to compile Linux with pcc to have a self-hosting system with only permissive stuff in userland :) [1] https://github.com/chneukirchen/obase/tree/musl [2] http://bsdfund.org/bundle/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 14:58 ` Jens Staal @ 2012-05-18 17:21 ` Christian Neukirchen 2012-05-18 18:43 ` Jens Staal 0 siblings, 1 reply; 18+ messages in thread From: Christian Neukirchen @ 2012-05-18 17:21 UTC (permalink / raw) To: musl Jens Staal <staal1978@gmail.com> writes: > 2012/5/17 Szabolcs Nagy <nsz@port70.net>: >> if you want to compile musl itself with pcc >> iirc you only have to change -lgcc into -lpcc >> in the Makefile >> > > > Very cool, so with obase-musl [1] and pcc self-hosting on musl, we > would only need the BSDfund challenge [2] to compile Linux with pcc to > have a self-hosting system with only permissive stuff in userland :) > > [1] https://github.com/chneukirchen/obase/tree/musl > [2] http://bsdfund.org/bundle/ obase-musl still lacks a lot due to many legacy syscalls musl probably won't implement. -- Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 17:21 ` Christian Neukirchen @ 2012-05-18 18:43 ` Jens Staal 2012-05-18 18:51 ` Kurt H Maier 0 siblings, 1 reply; 18+ messages in thread From: Jens Staal @ 2012-05-18 18:43 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 204 bytes --] > obase-musl still lacks a lot due to many legacy syscalls musl probably > won't implement. > > -- > Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org Could libbsd help with those? [-- Attachment #2: Type: text/html, Size: 360 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 18:43 ` Jens Staal @ 2012-05-18 18:51 ` Kurt H Maier 2012-05-18 22:58 ` Rich Felker 0 siblings, 1 reply; 18+ messages in thread From: Kurt H Maier @ 2012-05-18 18:51 UTC (permalink / raw) To: musl 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. > > > > -- > > Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org > > Could libbsd help with those? Is it really worth adding on more and more cruft just to get a base system working? In my opinion it would be better to flesh out sbase[1] or something like it. Requiring a compatibility shim for your core utilities sounds like a bad day waiting to happen. [1] - http://hg.suckless.org/sbase ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 18:51 ` Kurt H Maier @ 2012-05-18 22:58 ` Rich Felker 2012-05-18 23:13 ` Kurt H Maier ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Rich Felker @ 2012-05-18 22:58 UTC (permalink / raw) To: musl On Fri, May 18, 2012 at 02:51:23PM -0400, Kurt H Maier 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. > > > > > > -- > > > Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org > > > > Could libbsd help with those? > > Is it really worth adding on more and more cruft just to get a base > system working? In my opinion it would be better to flesh out sbase[1] > or something like it. Requiring a compatibility shim for your core > utilities sounds like a bad day waiting to happen. If there are really _syscalls_ not implemented, I'd be interested in knowing what they are. 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). 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. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 22:58 ` Rich Felker @ 2012-05-18 23:13 ` Kurt H Maier 2012-05-19 0:45 ` Isaac Dunham 2012-05-19 21:26 ` gcc segfault at src/mman/mlockall.c Christian Neukirchen 2 siblings, 0 replies; 18+ messages in thread From: Kurt H Maier @ 2012-05-18 23:13 UTC (permalink / raw) To: musl On Fri, May 18, 2012 at 06:58:45PM -0400, Rich Felker wrote: > > 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. Hence "flesh out" rather than "deploy." ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 22:58 ` Rich Felker 2012-05-18 23:13 ` Kurt H Maier @ 2012-05-19 0:45 ` Isaac Dunham 2012-05-19 0:56 ` Rich Felker 2012-05-19 21:26 ` gcc segfault at src/mman/mlockall.c Christian Neukirchen 2 siblings, 1 reply; 18+ messages in thread From: Isaac Dunham @ 2012-05-19 0:45 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-19 0:45 ` Isaac Dunham @ 2012-05-19 0:56 ` Rich Felker 2012-05-19 18:45 ` noXCUse, userspace options Isaac Dunham 2012-05-24 6:16 ` noXCUse grep Isaac Dunham 0 siblings, 2 replies; 18+ messages in thread From: Rich Felker @ 2012-05-19 0:56 UTC (permalink / raw) To: musl On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote: > > 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? It's on git.etalabs.net. I didn't put any effort into the release; it's mostly code I had around from years ago. Only grep is new. Here's the gitweb link: http://git.etalabs.net/cgi-bin/gitweb.cgi > While we're enumerating permissively-licensed userspaces, we might as Actually mine are still GPL or LGPL (I forget which), but I have no objection to relicensing them. I can do it sometime soon if anybody's interested. > well remember Android's toolbox, Somehow I doubt this works at all... > and more relevantly toybox (Landley's > project that set off the whole discussion of licensing). Yes, toybox is quite interesting but incomplete. In the long term it's probably going to be the best option, though, especially if Rob ends up being responsive about issues that come up... (Like my recent finding that xargs is doing what many ppl wrongly assume it does, rather than what it's actually supposed to do.) > 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. But how many of them aim to implement POSIX compatible utilities, and of those, how many come close to succeeding? Tools that are rough lookalikes/workalikes for the standard tools but which behave differently in subtle ways are rather useless for the purpose of running third-party scripts (including configure scripts). > So it isn't like there's a lack of options, it's just that none of > them seem to be ready at present. I agree there are several options, but not quite as many as you think. > 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. GNU make is by far the best/only decent make. If anybody really cares that much about permissive license, they're free to make a clone, but since GNU make is self-contained, extremely portable, clean code, I think refusing to use it on the basis of license is silly. It's not like other GNU packages that give you plenty of technical reasons to dislike them in addition to whatever your ideological reasons are. Rich ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: noXCUse, userspace options 2012-05-19 0:56 ` Rich Felker @ 2012-05-19 18:45 ` Isaac Dunham 2012-05-24 6:16 ` noXCUse grep Isaac Dunham 1 sibling, 0 replies; 18+ messages in thread From: Isaac Dunham @ 2012-05-19 18:45 UTC (permalink / raw) To: musl On Fri, 18 May 2012 20:56:55 -0400 Rich Felker <dalias@aerifal.cx> wrote: > On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote: > > > 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? > > It's on git.etalabs.net. I didn't put any effort into the release; > it's mostly code I had around from years ago. Only grep is new. Here's > the gitweb link: > > http://git.etalabs.net/cgi-bin/gitweb.cgi > > > While we're enumerating permissively-licensed userspaces... > Actually mine are still GPL or LGPL (I forget which), but I have no > objection to relicensing them. I can do it sometime soon if anybody's > interested. I'd assumed that it was permissively-licensed because you mentioned it in a thread that started with: |Very cool, so with obase-musl [1] and pcc self-hosting on musl, we |would only need the BSDfund challenge [2] to compile Linux with pcc to |have a self-hosting system with only permissive stuff in userland :) Your call on license. But if the discussion is about a permissively-licensed userspace, mentioning a GPL one seems a bit odd. > > well remember Android's toolbox, > Somehow I doubt this works at all... Enough to boot Android, that's all. I guess strike that. > > and more relevantly toybox (Landley's > > project that set off the whole discussion of licensing). > Yes, toybox is quite interesting but incomplete. In the long term it's > probably going to be the best option, though, especially if Rob ends > up being responsive about issues that come up... (Like my recent > finding that xargs is doing what many ppl wrongly assume it does, > rather than what it's actually supposed to do.) > > 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. > > But how many of them aim to implement POSIX compatible utilities, and > of those, how many come close to succeeding? Tools that are rough > lookalikes/workalikes for the standard tools but which behave > differently in subtle ways are rather useless for the purpose of > running third-party scripts (including configure scripts). Implement POSIXish utilities: at least the NetBSD utilities, heirloom (they have multiple personalities, one being xpg). Aim at POSIX-like: those plus obase (by virtue of bing a port of OpenBSD's usrspace, which is fairly close to conformant) Farther upthread, it was indicated that the goal isn't a POSIX userspace, but a self-hosting one. > > So it isn't like there's a lack of options, it's just that none of > > them seem to be ready at present. > I agree there are several options, but not quite as many as you think. Option: project aims to provide something that could be used for a self-hosting permissively-licensed userspace, as per the quote I referred to. Full POSIX/SUS4 conformance is not mandatory, as long as builds work. Ready: usable at present for a self-hosting environment. In other words, "Plenty of projects aim to be usable for this, but few of them are." > > 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. > GNU make is by far the best/only decent make. If anybody really cares > that much about permissive license, they're free to make a clone, but > since GNU make is self-contained, extremely portable, clean code, I > think refusing to use it on the basis of license is silly... The person who started this discussion was talking about a permissively licensed userspace. While I agree that a fully permissive userspace isn't really sensible, I thought I'd best clarify that they're underestimating the work. Isaac Dunham ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: noXCUse grep 2012-05-19 0:56 ` Rich Felker 2012-05-19 18:45 ` noXCUse, userspace options Isaac Dunham @ 2012-05-24 6:16 ` Isaac Dunham 1 sibling, 0 replies; 18+ messages in thread From: Isaac Dunham @ 2012-05-24 6:16 UTC (permalink / raw) To: musl On Fri, 18 May 2012 20:56:55 -0400 Rich Felker <dalias@aerifal.cx> wrote: > On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote: > > > 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? > > It's on git.etalabs.net. I didn't put any effort into the release; > it's mostly code I had around from years ago. Only grep is new. Here's > the gitweb link: > > http://git.etalabs.net/cgi-bin/gitweb.cgi By the way, I was trying to build pcc and configure failed at grep, when I used noXCUse grep (but not with busybox grep)--the test was for a grep version supporting long lines and -e, IIRC. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: gcc segfault at src/mman/mlockall.c 2012-05-18 22:58 ` Rich Felker 2012-05-18 23:13 ` Kurt H Maier 2012-05-19 0:45 ` Isaac Dunham @ 2012-05-19 21:26 ` Christian Neukirchen 2 siblings, 0 replies; 18+ messages in thread From: Christian Neukirchen @ 2012-05-19 21:26 UTC (permalink / raw) To: musl Rich Felker <dalias@aerifal.cx> writes: > On Fri, May 18, 2012 at 02:51:23PM -0400, Kurt H Maier 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. >> > > >> > > -- >> > > Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org >> > >> > Could libbsd help with those? >> >> Is it really worth adding on more and more cruft just to get a base >> system working? In my opinion it would be better to flesh out sbase[1] >> or something like it. Requiring a compatibility shim for your core >> utilities sounds like a bad day waiting to happen. > > If there are really _syscalls_ not implemented, I'd be interested in > knowing what they are. Sorry, not syscalls; I mean BSD libc functions such as fts(3). -- Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2012-05-24 6:16 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-05-15 16:35 gcc segfault at src/mman/mlockall.c Isaac Dunham 2012-05-15 16:42 ` Isaac Dunham 2012-05-15 19:21 ` Szabolcs Nagy 2012-05-15 19:30 ` Szabolcs Nagy 2012-05-16 18:53 ` Isaac Dunham 2012-05-16 22:04 ` Szabolcs Nagy 2012-05-17 6:07 ` Isaac Dunham 2012-05-18 14:58 ` Jens Staal 2012-05-18 17:21 ` Christian Neukirchen 2012-05-18 18:43 ` Jens Staal 2012-05-18 18:51 ` Kurt H Maier 2012-05-18 22:58 ` Rich Felker 2012-05-18 23:13 ` Kurt H Maier 2012-05-19 0:45 ` Isaac Dunham 2012-05-19 0:56 ` Rich Felker 2012-05-19 18:45 ` noXCUse, userspace options Isaac Dunham 2012-05-24 6:16 ` noXCUse grep Isaac Dunham 2012-05-19 21:26 ` gcc segfault at src/mman/mlockall.c Christian Neukirchen
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).