From rob at landley.net Thu Oct 1 09:47:43 2015 From: rob at landley.net (Rob Landley) Date: Thu, 1 Oct 2015 04:47:43 -0500 Subject: [Aboriginal] 1.4.2 is up. In-Reply-To: References: <55F68C51.2050106@landley.net> Message-ID: <560D013F.6090007@landley.net> On 09/25/2015 06:57 PM, alain.toussaint at securivm.ca wrote: > I'd be interested into making it work with risc-v but I suspect the PITA would the old gcc on host & target. > > Any other potential pitfalls? The other pitfall is uClibc, which hasn't had a healthy development process for most of a decade now and had its last release in 2012. I'm slowly migrating over to musl-libc, which has its own toolchain build (using current packages) at https://github.com/richfelker/musl-cross-make The hard part is we need cross _and_ native compilers to make aboriginal work. Everybody makes cross compilers, nobody but me seems to make native compilers. :( A good first step would probably be to get risc-v support into musl? Rob From vda.linux at googlemail.com Mon Oct 5 11:28:58 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Oct 2015 13:28:58 +0200 Subject: [Aboriginal] system-images 1.4.2: od is broken; bzip2 is missing Message-ID: Hi Rob, folks, I was playing with building busybox using Aboriginal Linux. (See busybox/qemu_multiarch_testing/README is you want to know the details). Used system-image-* from September 12 2015 from http://landley.net/aboriginal/downloads/binaries/ Looks like od is buggy on arm* and mips*: the first number on each line (the address) is bogus: On arm*: # echo Hello-hello-hello-hello | od -b 0000000 110 145 154 154 157 055 150 145 154 154 157 055 150 145 154 154 0000000 157 055 150 145 154 154 157 012 0000000 On mips[el]: # echo Hello-hello-hello-hello | od -b 0000000 110 145 154 154 157 055 150 145 154 154 157 055 150 145 154 154 17767153361 157 055 150 145 154 154 157 012 0000000 Broken on powerpc too. Works on x86. I noticed that system images no longer have bzip2. I think it was removed in an effort to reduce the number of tools necessary to the bare minimum? Maybe it's worth it. But just FYI, this did add another wrinkle to my use case. Re musl: two cases of breakage: #include #include results in: In file included from /usr/include/linux/if_bridge.h:18, from networking/brctl.c:67: /usr/include/linux/in6.h:32: error: redefinition of 'struct in6_addr' /usr/include/linux/in6.h:49: error: redefinition of 'struct sockaddr_in6' /usr/include/linux/in6.h:59: error: redefinition of 'struct ipv6_mreq' and #include #include results in: In file included from /usr/include/net/ethernet.h:10, from networking/ifplugd.c:41: /usr/include/netinet/if_ether.h:96: error: redefinition of 'struct ethhdr' From rob at landley.net Mon Oct 5 15:08:10 2015 From: rob at landley.net (Rob Landley) Date: Mon, 5 Oct 2015 10:08:10 -0500 Subject: [Aboriginal] system-images 1.4.2: od is broken; bzip2 is missing In-Reply-To: References: Message-ID: <5612925A.4070402@landley.net> On 10/05/2015 06:28 AM, Denys Vlasenko wrote: > Hi Rob, folks, > > I was playing with building busybox using Aboriginal Linux. > (See busybox/qemu_multiarch_testing/README is you want > to know the details). > > Used system-image-* from September 12 2015 from > http://landley.net/aboriginal/downloads/binaries/ > > Looks like od is buggy on arm* and mips*: > the first number on each line (the address) is bogus: > > On arm*: > # echo Hello-hello-hello-hello | od -b > 0000000 110 145 154 154 157 055 150 145 154 154 157 055 150 145 154 154 > 0000000 157 055 150 145 154 154 157 012 > 0000000 Blah. I'll fix it, thanks for the heads up. > On mips[el]: > # echo Hello-hello-hello-hello | od -b > 0000000 110 145 154 154 157 055 150 145 154 154 157 055 150 145 154 154 > 17767153361 157 055 150 145 154 154 157 012 > 0000000 > > Broken on powerpc too. > Works on x86. > > I noticed that system images no longer have bzip2. > I think it was removed in an effort to reduce the number of tools > necessary to the bare minimum? Yup. Aboriginal itself switched to gzip compression, and the Linux From Scratch build doesn't use it either. (Dunno about the 7.7 update I'm doing, not finished yet.) I plan to include gzip compression support to toybox (it's halfway written, actually). I've decided not to implement bzip2 compression side (even though I wrote half of it way back when) because the archive format is falling out of use. (For example the kernel switched from bz2 to xz archives.) I might include xz compression side support at some point, but that's large and fiddly and not a priority for 1.0. > Maybe it's worth it. But just FYI, this did add another wrinkle to my use case. Sorry. I'll try to get gzip in soonish. > Re musl: two cases of breakage: > > #include > #include > results in: > In file included from /usr/include/linux/if_bridge.h:18, > from networking/brctl.c:67: > /usr/include/linux/in6.h:32: error: redefinition of 'struct in6_addr' > /usr/include/linux/in6.h:49: error: redefinition of 'struct sockaddr_in6' > /usr/include/linux/in6.h:59: error: redefinition of 'struct ipv6_mreq' > > and > > #include > #include > results in: > In file included from /usr/include/net/ethernet.h:10, > from networking/ifplugd.c:41: > /usr/include/netinet/if_ether.h:96: error: redefinition of 'struct ethhdr' > That I leave to Rich. :) Rob From dalias at aerifal.cx Tue Oct 6 01:44:26 2015 From: dalias at aerifal.cx (Rich Felker) Date: Mon, 5 Oct 2015 21:44:26 -0400 Subject: [Aboriginal] musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <5612925A.4070402@landley.net> References: <5612925A.4070402@landley.net> Message-ID: <20151006014426.GL8645@brightrain.aerifal.cx> On Mon, Oct 05, 2015 at 10:08:10AM -0500, Rob Landley wrote: > > Re musl: two cases of breakage: > > > > #include > > #include > > results in: > > In file included from /usr/include/linux/if_bridge.h:18, > > from networking/brctl.c:67: > > /usr/include/linux/in6.h:32: error: redefinition of 'struct in6_addr' > > /usr/include/linux/in6.h:49: error: redefinition of 'struct sockaddr_in6' > > /usr/include/linux/in6.h:59: error: redefinition of 'struct ipv6_mreq' > > > > and > > > > #include > > #include > > results in: > > In file included from /usr/include/net/ethernet.h:10, > > from networking/ifplugd.c:41: > > /usr/include/netinet/if_ether.h:96: error: redefinition of 'struct ethhdr' > > > > That I leave to Rich. :) Including kernel headers is just really problematic. These days they try to make it work on glibc with a complex dance between glibc's headers and the kernel headers. You're likely to have the best luck by including the libc headers first. I think Sabotage and possibly some other musl-based dists are patching the kernel headers to make them behave better; see: https://github.com/sabotage-linux/sabotage/blob/master/pkg/kernel-headers But it might be possible that we can just #define whatever macro the kernel headers expect to suppress redefinitions, if it's in a reserved namespace. This would only fix the case where the kernel headers are included _after_ the libc/userspace ones, but it's not too ugly. I probably won't get around to it myself but if anyone wants to check what macros we'd need to define (and where), let's discuss it (cc'ing musl list). The cleaner approach is just avoiding including both the kernel headers and libc/userspace headers for the same things in the same file. In theory this may be hard in some cases, but I find that I can almost always fix these sorts of errors during a build by commenting out one or two #include lines. Rich From rob at landley.net Tue Oct 6 02:24:01 2015 From: rob at landley.net (Rob Landley) Date: Mon, 5 Oct 2015 21:24:01 -0500 Subject: [Aboriginal] musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151006014426.GL8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> Message-ID: <561330C1.8070205@landley.net> On 10/05/2015 08:44 PM, Rich Felker wrote: > On Mon, Oct 05, 2015 at 10:08:10AM -0500, Rob Landley wrote: > The cleaner approach is just avoiding including both the kernel > headers and libc/userspace headers for the same things in the same > file. In theory this may be hard in some cases, but I find that I can > almost always fix these sorts of errors during a build by commenting > out one or two #include lines. I am _deeply_ curious how you'd get linux/loop.h on a platform where you need the 32 bit loopback structure definition without including the kernel header. I struggled with that one a lot back in the busybox days. (For the 64 bit version you can block copy the structure out of the header into your program, just like you can block copy everything out of headers and never actually #include anything, in the name of portability!) Sadly, the kernel headers are exported for a _reason_. If I need to syscall something you haven't wrapped, I need the _NR_ and it varies per target. It's a thing. Rob From rob at landley.net Tue Oct 6 04:02:48 2015 From: rob at landley.net (Rob Landley) Date: Mon, 5 Oct 2015 23:02:48 -0500 Subject: [Aboriginal] system-images 1.4.2: od is broken; bzip2 is missing In-Reply-To: References: Message-ID: <561347E8.5000605@landley.net> On 10/05/2015 06:28 AM, Denys Vlasenko wrote: > On mips[el]: > # echo Hello-hello-hello-hello | od -b > 0000000 110 145 154 154 157 055 150 145 154 154 157 055 150 145 154 154 > 17767153361 157 055 150 145 154 154 157 012 > 0000000 It was because off_t varied in size and I was treating it as "int" in a printf. My bad. Fix checked in to toybox, should be in the next aboriginal release. (Maybe this weekend?) > I noticed that system images no longer have bzip2. > I think it was removed in an effort to reduce the number of tools > necessary to the bare minimum? > Maybe it's worth it. But just FYI, this did add another wrinkle to my use case. Could you describe your use case a little more? If I have a build control image to test against, I can try to make sure it still works each release. (I note that the x86-64 target has switched over to musl by default, and other targets are likely to do the same in upcoming releases. I'm slowly weaning off uClibc because it's dead. Yes I'm aware of uClibc-ng, which strikes me as the ecommstation of libraries. That ship has sailed.) Rob From dalias at aerifal.cx Tue Oct 6 14:30:18 2015 From: dalias at aerifal.cx (Rich Felker) Date: Tue, 6 Oct 2015 10:30:18 -0400 Subject: [Aboriginal] musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <561330C1.8070205@landley.net> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <561330C1.8070205@landley.net> Message-ID: <20151006143018.GN8645@brightrain.aerifal.cx> On Mon, Oct 05, 2015 at 09:24:01PM -0500, Rob Landley wrote: > On 10/05/2015 08:44 PM, Rich Felker wrote: > > On Mon, Oct 05, 2015 at 10:08:10AM -0500, Rob Landley wrote: > > The cleaner approach is just avoiding including both the kernel > > headers and libc/userspace headers for the same things in the same > > file. In theory this may be hard in some cases, but I find that I can > > almost always fix these sorts of errors during a build by commenting > > out one or two #include lines. > > I am _deeply_ curious how you'd get linux/loop.h on a platform where you > need the 32 bit loopback structure definition without including the > kernel header. Sorry I wasn't clear on this; the meaning I intended to convey was including both kernel and libc/userspace headers for the same things. Network is the main area affected here. The kernel headers have fixed up all the gratuitous conflicts with userspace, but the big remaining ones are places where they want to define types with the exact same names, which mostly happens in network. So what I was trying to say is that programs using kernel network headers (legitimately for linux-specific stuff) are going to best avoid the risk of clashes by not including libc network headers in the same files. > Sadly, the kernel headers are exported for a _reason_. If I need to > syscall something you haven't wrapped, I need the _NR_ and it varies per > target. It's a thing. For syscalls we export all SYS_*/__NR_* macros (sys/syscall.h), but you still might need macro and struct definitions for arguments to the syscalls or ioctls. Rich From vda.linux at googlemail.com Tue Oct 6 15:50:11 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 Oct 2015 17:50:11 +0200 Subject: [Aboriginal] system-images 1.4.2: od is broken; bzip2 is missing In-Reply-To: <561347E8.5000605@landley.net> References: <561347E8.5000605@landley.net> Message-ID: On Tue, Oct 6, 2015 at 6:02 AM, Rob Landley wrote: >> I noticed that system images no longer have bzip2. >> I think it was removed in an effort to reduce the number of tools >> necessary to the bare minimum? >> Maybe it's worth it. But just FYI, this did add another wrinkle to my use case. > > Could you describe your use case a little more? See http://git.busybox.net/busybox/tree/qemu_multiarch_testing/README ================================ How to test build using Aboriginal Linux system images. * Put a source tree into hdc.dir/. For example, this should work: git clone git://busybox.net/var/lib/git/busybox.git * Run ./make-hdc-img.sh: it will generate ext2 image file, hdc.img, from hdc.dir/* data. This requires root for loop mount. * Download and unpack, or build from source and unpack one or more system-image-ARCH directories into this directory (the one which contains this README). * Run: ./parallel-build-hdc-img.sh system-image-DIR1 system-image-DIR2... (background it if you don't want to see "Waiting to finish" thing). This runs build in several qemu virtual machines in parallel. * Observe system-image-*.log file(s) with growing log of the build. ================================ Now look in hdc.dir/build: http://git.busybox.net/busybox/tree/qemu_multiarch_testing/hdc.dir/build ... make defconfig # Want static build sed 's/^.*CONFIG_STATIC.*$/CONFIG_STATIC=y/' -i .config bzip2 /dev/null || { # Drats, newer Aboriginal Linux has no bzip2 sed 's/^.*CONFIG_FEATURE_COMPRESS_USAGE.*$/# CONFIG_FEATURE_COMPRESS_USAGE is not set/' -i .config } # These won't build because of toolchain/libc breakage: sed 's/^.*CONFIG_FEATURE_SYNC_FANCY.*$/# CONFIG_FEATURE_SYNC_FANCY is not set/' -i .config # no syncfs() sed 's/^.*CONFIG_FEATURE_WTMP.*$/# CONFIG_FEATURE_WTMP is not set/' -i .config sed 's/^.*CONFIG_FEATURE_UTMP.*$/# CONFIG_FEATURE_UTMP is not set/' -i .config sed 's/^.*CONFIG_FEATURE_INETD_RPC.*$/# CONFIG_FEATURE_INETD_RPC is not set/' -i .config make ... As you see, I have to unset CONFIG_FEATURE_COMPRESS_USAGE because it requires bzip2. > I note that the x86-64 target has switched over to musl by default, and > other targets are likely to do the same in upcoming releases. I'm slowly > weaning off uClibc because it's dead. I know. This broke only two applets in bbox (now worked around in bbox git), and three FEATURE configs had to be switched off. From vda.linux at googlemail.com Tue Oct 6 16:05:52 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 Oct 2015 18:05:52 +0200 Subject: [Aboriginal] musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151006143018.GN8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <561330C1.8070205@landley.net> <20151006143018.GN8645@brightrain.aerifal.cx> Message-ID: On Tue, Oct 6, 2015 at 4:30 PM, Rich Felker wrote: > On Mon, Oct 05, 2015 at 09:24:01PM -0500, Rob Landley wrote: >> On 10/05/2015 08:44 PM, Rich Felker wrote: >> > The cleaner approach is just avoiding including both the kernel >> > headers and libc/userspace headers for the same things in the same >> > file. In theory this may be hard in some cases, but I find that I can >> > almost always fix these sorts of errors during a build by commenting >> > out one or two #include lines. >> >> I am _deeply_ curious how you'd get linux/loop.h on a platform where you >> need the 32 bit loopback structure definition without including the >> kernel header. > > Sorry I wasn't clear on this; the meaning I intended to convey was > including both kernel and libc/userspace headers for the same things. > Network is the main area affected here. The kernel headers have fixed > up all the gratuitous conflicts with userspace, but the big remaining > ones are places where they want to define types with the exact same > names, which mostly happens in network. So what I was trying to say is > that programs using kernel network headers (legitimately for > linux-specific stuff) are going to best avoid the risk of clashes by > not including libc network headers in the same files. For me as a libc user, the gist of the story is: I switch to musl, things break. Apart from linux/* includes, utmp/wtmp also broke. From vda.linux at googlemail.com Tue Oct 6 16:09:15 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 Oct 2015 18:09:15 +0200 Subject: [Aboriginal] musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151006014426.GL8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> Message-ID: On Tue, Oct 6, 2015 at 3:44 AM, Rich Felker wrote: >> > >> > #include >> > #include >> > results in: >> > In file included from /usr/include/linux/if_bridge.h:18, >> > from networking/brctl.c:67: >> > /usr/include/linux/in6.h:32: error: redefinition of 'struct in6_addr' >> > /usr/include/linux/in6.h:49: error: redefinition of 'struct sockaddr_in6' >> > /usr/include/linux/in6.h:59: error: redefinition of 'struct ipv6_mreq' >> > >> > and >> > >> > #include >> > #include >> > results in: >> > In file included from /usr/include/net/ethernet.h:10, >> > from networking/ifplugd.c:41: >> > /usr/include/netinet/if_ether.h:96: error: redefinition of 'struct ethhdr' >> > >> >> That I leave to Rich. :) > > Including kernel headers is just really problematic. These days they > try to make it work on glibc with a complex dance between glibc's > headers and the kernel headers. You're likely to have the best luck by > including the libc headers first. brctl.c was including after From lamiaworks at skymesh.com.au Wed Oct 7 04:49:19 2015 From: lamiaworks at skymesh.com.au (lamiaworks) Date: Wed, 07 Oct 2015 15:49:19 +1100 Subject: [Aboriginal] system-images, 1.4.2: od is broken; bzip2 is missing In-Reply-To: References: Message-ID: <5614A44F.7090509@skymesh.com.au> >> I noticed that system images no longer have bzip2. >> I think it was removed in an effort to reduce the number of tools >> necessary to the bare minimum? > > Yup. Aboriginal itself switched to gzip compression, and the Linux From > Scratch build doesn't use it either. (Dunno about the 7.7 update I'm > doing, not finished yet.) > > I plan to include gzip compression support to toybox (it's halfway > written, actually). I've decided not to implement bzip2 compression side > (even though I wrote half of it way back when) because the archive > format is falling out of use. (For example the kernel switched from bz2 > to xz archives.) > > I might include xz compression side support at some point, but that's > large and fiddly and not a priority for 1.0. > um..., any chance of leaving bz2 in for now at least Rob as those of us working with T2 which still uses it (pretty please), at least until xz is in. thanks scsijon From rob at landley.net Wed Oct 7 00:41:36 2015 From: rob at landley.net (Rob Landley) Date: Tue, 6 Oct 2015 19:41:36 -0500 Subject: [Aboriginal] system-images, 1.4.2: od is broken; bzip2 is missing In-Reply-To: <5614A44F.7090509@skymesh.com.au> References: <5614A44F.7090509@skymesh.com.au> Message-ID: <56146A40.10609@landley.net> On 10/06/2015 11:49 PM, lamiaworks wrote: > >>> I noticed that system images no longer have bzip2. >>> I think it was removed in an effort to reduce the number of tools >>> necessary to the bare minimum? >> >> Yup. Aboriginal itself switched to gzip compression, and the Linux From >> Scratch build doesn't use it either. (Dunno about the 7.7 update I'm >> doing, not finished yet.) >> >> I plan to include gzip compression support to toybox (it's halfway >> written, actually). I've decided not to implement bzip2 compression side >> (even though I wrote half of it way back when) because the archive >> format is falling out of use. (For example the kernel switched from bz2 >> to xz archives.) >> >> I might include xz compression side support at some point, but that's >> large and fiddly and not a priority for 1.0. >> > > um..., any chance of leaving bz2 in for now at least Rob as those of us > working with T2 which still uses it (pretty please), at least until xz > is in. Ok, I'll switch it back on next release. What's T2? Rob From dalias at aerifal.cx Thu Oct 8 16:58:08 2015 From: dalias at aerifal.cx (Rich Felker) Date: Thu, 8 Oct 2015 12:58:08 -0400 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> Message-ID: <20151008165808.GZ8645@brightrain.aerifal.cx> On Tue, Oct 06, 2015 at 06:09:15PM +0200, Denys Vlasenko wrote: > On Tue, Oct 6, 2015 at 3:44 AM, Rich Felker wrote: > >> > > >> > #include > >> > #include > >> > results in: > >> > In file included from /usr/include/linux/if_bridge.h:18, > >> > from networking/brctl.c:67: > >> > /usr/include/linux/in6.h:32: error: redefinition of 'struct in6_addr' > >> > /usr/include/linux/in6.h:49: error: redefinition of 'struct sockaddr_in6' > >> > /usr/include/linux/in6.h:59: error: redefinition of 'struct ipv6_mreq' > >> > > >> > and > >> > > >> > #include > >> > #include > >> > results in: > >> > In file included from /usr/include/net/ethernet.h:10, > >> > from networking/ifplugd.c:41: > >> > /usr/include/netinet/if_ether.h:96: error: redefinition of 'struct ethhdr' > >> > > >> > >> That I leave to Rich. :) > > > > Including kernel headers is just really problematic. These days they > > try to make it work on glibc with a complex dance between glibc's > > headers and the kernel headers. You're likely to have the best luck by > > including the libc headers first. > > brctl.c was including after The problem is linux/libc-compat.h, which should fix this, only works on glibc, by design. See: #ifndef _LIBC_COMPAT_H #define _LIBC_COMPAT_H /* We have included glibc headers... */ #if defined(__GLIBC__) /* Coordinate with glibc netinet/in.h header. */ #if defined(_NETINET_IN_H) If you patch it like this: -#if defined(__GLIBC__) +#if 1 then it should mostly work but it's still all a big hack. I think that's what distros are doing. The problem is that the same header is trying to do two different things: 1. Provide extra linux-kernel-API stuff that's not in the libc/userspace headers. 2. Provide definitions of the standard types and constants for uClibc and klibc, which don't have complete libc headers and rely on the kernel headers for definitions. These two uses really should be separated out into separate headers so that the latter only get included explicitly by uClibc and klibc and otherwise remain completely unused. But that would require coordinated changes/upgrades which are unlikely to happen. :( Rich From vda.linux at googlemail.com Fri Oct 9 19:11:08 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 9 Oct 2015 21:11:08 +0200 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151008165808.GZ8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> Message-ID: On Thu, Oct 8, 2015 at 6:58 PM, Rich Felker wrote: >> > Including kernel headers is just really problematic. These days they >> > try to make it work on glibc with a complex dance between glibc's >> > headers and the kernel headers. You're likely to have the best luck by >> > including the libc headers first. >> >> brctl.c was including after > > The problem is linux/libc-compat.h, which should fix this, only works > on glibc, by design. See: > > #ifndef _LIBC_COMPAT_H > #define _LIBC_COMPAT_H > > /* We have included glibc headers... */ > #if defined(__GLIBC__) > > /* Coordinate with glibc netinet/in.h header. */ > #if defined(_NETINET_IN_H) > > If you patch it like this: > > -#if defined(__GLIBC__) > +#if 1 > > then it should mostly work but it's still all a big hack. I think > that's what distros are doing. The problem is that the same header is > trying to do two different things: > > 1. Provide extra linux-kernel-API stuff that's not in the > libc/userspace headers. > > 2. Provide definitions of the standard types and constants for uClibc > and klibc, which don't have complete libc headers and rely on the > kernel headers for definitions. > > These two uses really should be separated out into separate headers so > that the latter only get included explicitly by uClibc and klibc and > otherwise remain completely unused. But that would require coordinated > changes/upgrades which are unlikely to happen. :( Looking at kernel's libc-compat.h, it looks like you can get away with using __UAPI_DEF_foo's like this? #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 /* kernel already defined the struct, do nothing */ #else struct sockaddr_in { ... }; #undef __UAPI_DEF_SOCKADDR_IN /* tell kernel to not define the struct */ #define __UAPI_DEF_SOCKADDR_IN 0 #endif From dalias at aerifal.cx Fri Oct 9 19:46:41 2015 From: dalias at aerifal.cx (Rich Felker) Date: Fri, 9 Oct 2015 15:46:41 -0400 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> Message-ID: <20151009194641.GI8645@brightrain.aerifal.cx> On Fri, Oct 09, 2015 at 09:11:08PM +0200, Denys Vlasenko wrote: > On Thu, Oct 8, 2015 at 6:58 PM, Rich Felker wrote: > >> > Including kernel headers is just really problematic. These days they > >> > try to make it work on glibc with a complex dance between glibc's > >> > headers and the kernel headers. You're likely to have the best luck by > >> > including the libc headers first. > >> > >> brctl.c was including after > > > > The problem is linux/libc-compat.h, which should fix this, only works > > on glibc, by design. See: > > > > #ifndef _LIBC_COMPAT_H > > #define _LIBC_COMPAT_H > > > > /* We have included glibc headers... */ > > #if defined(__GLIBC__) > > > > /* Coordinate with glibc netinet/in.h header. */ > > #if defined(_NETINET_IN_H) > > > > If you patch it like this: > > > > -#if defined(__GLIBC__) > > +#if 1 > > > > then it should mostly work but it's still all a big hack. I think > > that's what distros are doing. The problem is that the same header is > > trying to do two different things: > > > > 1. Provide extra linux-kernel-API stuff that's not in the > > libc/userspace headers. > > > > 2. Provide definitions of the standard types and constants for uClibc > > and klibc, which don't have complete libc headers and rely on the > > kernel headers for definitions. > > > > These two uses really should be separated out into separate headers so > > that the latter only get included explicitly by uClibc and klibc and > > otherwise remain completely unused. But that would require coordinated > > changes/upgrades which are unlikely to happen. :( > > Looking at kernel's libc-compat.h, it looks like you can get away > with using __UAPI_DEF_foo's like this? > > > #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 > /* kernel already defined the struct, do nothing */ > #else > struct sockaddr_in { > ... > }; This would address the case where the kernel header is included first, but it's not a case I or most of the musl community wants to support, because there's no guarantee that the kernel's definitions of these structures will actually be compatible with use elsewhere in the libc headers, etc. The other direction, suppressing kernel headers' definition of the structs, is what we want to work, but they've restricted their logic for that to only work when __GLIBC__ is defined. :( > #undef __UAPI_DEF_SOCKADDR_IN > /* tell kernel to not define the struct */ > #define __UAPI_DEF_SOCKADDR_IN 0 > #endif We could do something like this but then we would need to keep up with the list of all the __UAPI defines we need to suppress unwanted kernel definitions. What if we could get the kernel to change the #if defined(__GLIBC__) to #if defined(__GLIBC__) || defined(__UAPI_DONTNEED_DEFS) or similar, so that there would only be one macro we need to define, and the kernel would then use the same logic it uses with glibc to suppress all of these. Rich From rob at landley.net Sat Oct 10 04:56:23 2015 From: rob at landley.net (Rob Landley) Date: Fri, 9 Oct 2015 23:56:23 -0500 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151009194641.GI8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> Message-ID: <56189A77.1010808@landley.net> On 10/09/2015 02:46 PM, Rich Felker wrote: > On Fri, Oct 09, 2015 at 09:11:08PM +0200, Denys Vlasenko wrote: >> #undef __UAPI_DEF_SOCKADDR_IN >> /* tell kernel to not define the struct */ >> #define __UAPI_DEF_SOCKADDR_IN 0 >> #endif > > We could do something like this but then we would need to keep up with > the list of all the __UAPI defines we need to suppress unwanted kernel > definitions. You have a bug report. This would fix it. Then wait for more bug reports? Rob From vda.linux at googlemail.com Mon Oct 12 23:48:20 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Oct 2015 01:48:20 +0200 Subject: [Aboriginal] Oy I am behind. In-Reply-To: <55DD6D76.1090909@landley.net> References: <55DD6D76.1090909@landley.net> Message-ID: On Wed, Aug 26, 2015 at 9:40 AM, Rob Landley wrote: > And that's on top of the nommu support stuff I've been doing for $DAYJOB... Rob, please note that hush had a nommu bug discovered recently. Testcase is a bit convoluted: func() { while read p; do echo "$p"; done } pipe_to_func() { # We had a NOMMU bug which caused "echo Ok |" part to be lost echo Ok | func } pipe_to_func | cat echo $? And also, there is an embarrassing simple bug: "umask N" actually sets umask ~N. I released busybox-1.24.0 with both fixed. From vda.linux at googlemail.com Tue Oct 13 00:00:39 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Oct 2015 02:00:39 +0200 Subject: [Aboriginal] Time for another release. In-Reply-To: <55B0650F.7020105@landley.net> References: <55B0650F.7020105@landley.net> Message-ID: On Thu, Jul 23, 2015 at 5:52 AM, Rob Landley wrote: > Bit past due, really. > > I got the sh2eb and sh2elf binflt toolchains working. Userspace isn't > yet because nommu, I tried switching ash out for hush but it still needs > fork(). No, hush definitely does not need fork(). It will use fork() if it _thinks_ it's being built for MMU machine. Set CONFIG_NOMMU=y to override that detection. Here is my test build: $ file busybox_unstripped busybox_unstripped: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped $ nm busybox_unstripped | grep fork 080dda8c W __GI_vfork 080dda8c T __vfork 0807eb17 t collect_fork 0804f896 t fork_job 080da68b T fork_or_rexec 080b00bd T fork_transformer 0807e54b t init_fork 080dda8c W vfork 080b0f3b t vfork_child 080a7dd3 t vfork_compressor As you see, the binary has no fork() function. $ ./busybox hush /usr/srcdevel/bbox/fix/busybox.t9 $ In fact, all busybox applets sans "ash" compile successfully with CONFIG_NOMMU=y, and should work. There can be bugs, of course. From rob at landley.net Tue Oct 13 03:16:30 2015 From: rob at landley.net (Rob Landley) Date: Mon, 12 Oct 2015 22:16:30 -0500 Subject: [Aboriginal] Oy I am behind. In-Reply-To: References: <55DD6D76.1090909@landley.net> Message-ID: <561C778E.2050404@landley.net> On 10/12/2015 06:48 PM, Denys Vlasenko wrote: > On Wed, Aug 26, 2015 at 9:40 AM, Rob Landley wrote: >> And that's on top of the nommu support stuff I've been doing for $DAYJOB... > > Rob, please note that hush had a nommu bug discovered recently. Sigh. Ok, updating to current busybox. > Testcase is a bit convoluted: > > func() > { > while read p; do echo "$p"; done > } > pipe_to_func() > { > # We had a NOMMU bug which caused "echo Ok |" part to be lost > echo Ok | func > } > pipe_to_func | cat > echo $? > > And also, there is an embarrassing simple bug: "umask N" > actually sets umask ~N. > > I released busybox-1.24.0 with both fixed. Updating broke http://landley.net/hg/aboriginal/file/tip/sources/patches/busybox-ftpd.patch which looks like it's still needed... Rob From vda.linux at googlemail.com Tue Oct 13 11:56:40 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Oct 2015 13:56:40 +0200 Subject: [Aboriginal] Oy I am behind. In-Reply-To: <561C778E.2050404@landley.net> References: <55DD6D76.1090909@landley.net> <561C778E.2050404@landley.net> Message-ID: On Tue, Oct 13, 2015 at 5:16 AM, Rob Landley wrote: > On 10/12/2015 06:48 PM, Denys Vlasenko wrote: >> On Wed, Aug 26, 2015 at 9:40 AM, Rob Landley wrote: >>> And that's on top of the nommu support stuff I've been doing for $DAYJOB... >> >> Rob, please note that hush had a nommu bug discovered recently. > > Sigh. Ok, updating to current busybox. > >> Testcase is a bit convoluted: >> >> func() >> { >> while read p; do echo "$p"; done >> } >> pipe_to_func() >> { >> # We had a NOMMU bug which caused "echo Ok |" part to be lost >> echo Ok | func >> } >> pipe_to_func | cat >> echo $? >> >> And also, there is an embarrassing simple bug: "umask N" >> actually sets umask ~N. >> >> I released busybox-1.24.0 with both fixed. > > Updating broke > http://landley.net/hg/aboriginal/file/tip/sources/patches/busybox-ftpd.patch > which looks like it's still needed... You want "ftpd DIR" to work also for non-root. Well, this can't be made to work _exactly_ as for root (where DIR becomes new rootdir), and I thought that to have a discrepancy is bad. I take your and other people's emails as an indication that in real world, it's acceptable for non-root invocation to simply chdir instead. Fixed in git. BTW, let me know if ftpd doesn't work in NOMMU, it had to do some weird stuff to avoid fork() http://git.busybox.net/busybox/commit/?id=f7ad927c2059ef9cd1cd6befeb43f26b92f6369f diff --git a/networking/ftpd.c b/networking/ftpd.c index 7735b72..8345ae6 100644 --- a/networking/ftpd.c +++ b/networking/ftpd.c @@ -1223,11 +1223,26 @@ int ftpd_main(int argc UNUSED_PARAM, char **argv) #endif argv += optind; if (argv[0]) { + const char *basedir = argv[0]; #if !BB_MMU G.root_fd = xopen("/", O_RDONLY | O_DIRECTORY); close_on_exec_on(G.root_fd); #endif - xchroot(argv[0]); + if (chroot(basedir) == 0) + basedir = "/"; +#if !BB_MMU + else { + close(G.root_fd); + G.root_fd = -1; + } +#endif + /* + * If chroot failed, assume that we aren't root, + * and at least chdir to the specified DIR + * (older versions were dying with error message). + * If chroot worked, move current dir to new "/": + */ + xchdir(basedir); } #if ENABLE_FEATURE_FTP_AUTHENTICATION From vda.linux at googlemail.com Tue Oct 13 12:10:24 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Oct 2015 14:10:24 +0200 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151009194641.GI8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> Message-ID: On Fri, Oct 9, 2015 at 9:46 PM, Rich Felker wrote: >> Looking at kernel's libc-compat.h, it looks like you can get away >> with using __UAPI_DEF_foo's like this? >> >> >> #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 >> /* kernel already defined the struct, do nothing */ >> #else >> struct sockaddr_in { >> ... >> }; > > This would address the case where the kernel header is included first, > but it's not a case I or most of the musl community wants to support, > because there's no guarantee that the kernel's definitions of these > structures will actually be compatible with use elsewhere in the libc > headers, etc. If kernel's definition does not match yours, there is a much bigger problem than "includes do not compile": kernel and userspace definitions of these structs *must* match (modulo harmless things like different typedef names for field types). So in this case either kernel or libc would need to be fixed. > The other direction, suppressing kernel headers' definition of the > structs, is what we want to work, but they've restricted their logic > for that to only work when __GLIBC__ is defined. :( Yes, you will have to do by hand the thing which kernel automagically does for glibc - namely, define to 0: >> #undef __UAPI_DEF_SOCKADDR_IN >> /* tell kernel to not define the struct */ >> #define __UAPI_DEF_SOCKADDR_IN 0 >> #endif > We could do something like this but then we would need to keep up with > the list of all the __UAPI defines we need to suppress unwanted kernel > definitions. Looking at libc-compat.h, this list is at the moment only about 13 defines long: #define __UAPI_DEF_IN_ADDR 0 #define __UAPI_DEF_IN_IPPROTO 0 #define __UAPI_DEF_IN_PKTINFO 0 #define __UAPI_DEF_IP_MREQ 0 #define __UAPI_DEF_SOCKADDR_IN 0 #define __UAPI_DEF_IN_CLASS 0 #define __UAPI_DEF_IN6_ADDR 0 #define __UAPI_DEF_SOCKADDR_IN6 0 #define __UAPI_DEF_IPV6_MREQ 0 #define __UAPI_DEF_IPPROTO_V6 0 #define __UAPI_DEF_IPV6_OPTIONS 0 #define __UAPI_DEF_IN6_PKTINFO 0 #define __UAPI_DEF_IP6_MTUINFO 0 > What if we could get the kernel to change the #if defined(__GLIBC__) > to #if defined(__GLIBC__) || defined(__UAPI_DONTNEED_DEFS) or similar, > so that there would only be one macro we need to define, and the > kernel would then use the same logic it uses with glibc to suppress > all of these. Or ask kernel to remove "define to 0" glibc hack and ask glibc to do its own job. Why one libc should have preferential treatment? Or ask kernel to stop using structures with userspace names. This should not be that hard: struct __kernel_sockaddr_in {...} #if __KERNEL__ # define sockaddr_in __kernel_sockaddr_in #endif From dalias at aerifal.cx Tue Oct 13 15:05:25 2015 From: dalias at aerifal.cx (Rich Felker) Date: Tue, 13 Oct 2015 11:05:25 -0400 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151013145335.GQ10551@port70.net> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> <20151013145335.GQ10551@port70.net> Message-ID: <20151013150525.GP8645@brightrain.aerifal.cx> On Tue, Oct 13, 2015 at 04:53:35PM +0200, Szabolcs Nagy wrote: > * Denys Vlasenko [2015-10-13 14:10:24 +0200]: > > On Fri, Oct 9, 2015 at 9:46 PM, Rich Felker wrote: > > >> Looking at kernel's libc-compat.h, it looks like you can get away > > >> with using __UAPI_DEF_foo's like this? > > >> > > >> > > >> #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 > > >> /* kernel already defined the struct, do nothing */ > > >> #else > > >> struct sockaddr_in { > > >> ... > > >> }; > > > > > > This would address the case where the kernel header is included first, > > > but it's not a case I or most of the musl community wants to support, > > > because there's no guarantee that the kernel's definitions of these > > > structures will actually be compatible with use elsewhere in the libc > > > headers, etc. > > > > If kernel's definition does not match yours, there is a much > > bigger problem than "includes do not compile": > > kernel and userspace definitions of these structs *must* match > > (modulo harmless things like different typedef names for field types). > > > > So in this case either kernel or libc would need to be fixed. > > why? > > in practice most types are c abi compatible with the kernel > because translating the types at the syscall boundary is > painful/impossible. > > but even with compatible binary representation there is > plenty space for disagreement between kernel and libc on > the source level. (of course code that includes both libc > and kernel headers might not care about posix namespace > violations or undefined behaviour in kernel headers..) > > and libc-compat does not cover all conflicting cases > (i assume they just add workarouds when somebody hits > a conflict), e.g. sys/inotify.h and linux/inotify.h are > in conflict (and linux/inotify.h is not even standard c). Indeed the problem here is source compatibility, not binary compatibility. Issues like names of types, choice of distinct types that have the same size and representation but which are not compatible types (which make problems if you take the address of the member, including possibly aliasing problems which are real-world bugs), etc. If static linking of libc is used along with LTO these could spill deep into internals and result in broken codegen. Rich From dalias at aerifal.cx Tue Oct 13 15:10:49 2015 From: dalias at aerifal.cx (Rich Felker) Date: Tue, 13 Oct 2015 11:10:49 -0400 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> Message-ID: <20151013151048.GQ8645@brightrain.aerifal.cx> On Tue, Oct 13, 2015 at 02:10:24PM +0200, Denys Vlasenko wrote: > > The other direction, suppressing kernel headers' definition of the > > structs, is what we want to work, but they've restricted their logic > > for that to only work when __GLIBC__ is defined. :( > > Yes, you will have to do by hand the thing which kernel > automagically does for glibc - namely, define to 0: > > >> #undef __UAPI_DEF_SOCKADDR_IN > >> /* tell kernel to not define the struct */ > >> #define __UAPI_DEF_SOCKADDR_IN 0 > >> #endif > > > We could do something like this but then we would need to keep up with > > the list of all the __UAPI defines we need to suppress unwanted kernel > > definitions. > > Looking at libc-compat.h, this list is at the moment only about > 13 defines long: > > #define __UAPI_DEF_IN_ADDR 0 > #define __UAPI_DEF_IN_IPPROTO 0 > #define __UAPI_DEF_IN_PKTINFO 0 > #define __UAPI_DEF_IP_MREQ 0 > #define __UAPI_DEF_SOCKADDR_IN 0 > #define __UAPI_DEF_IN_CLASS 0 > #define __UAPI_DEF_IN6_ADDR 0 > #define __UAPI_DEF_SOCKADDR_IN6 0 > #define __UAPI_DEF_IPV6_MREQ 0 > #define __UAPI_DEF_IPPROTO_V6 0 > #define __UAPI_DEF_IPV6_OPTIONS 0 > #define __UAPI_DEF_IN6_PKTINFO 0 > #define __UAPI_DEF_IP6_MTUINFO 0 Thanks for making the list! For the time being I don't think it would be too objectionable to simply define these in musl. Does anyone else have an opinion on it? > > What if we could get the kernel to change the #if defined(__GLIBC__) > > to #if defined(__GLIBC__) || defined(__UAPI_DONTNEED_DEFS) or similar, > > so that there would only be one macro we need to define, and the > > kernel would then use the same logic it uses with glibc to suppress > > all of these. > > Or ask kernel to remove "define to 0" glibc hack and ask glibc to > do its own job. Why one libc should have preferential treatment? Well they don't want regressions; changing this would make old versions of glibc break. Presumably before all this UAPI "cleanup" (I'm not sure it can really be called "clean" though) there was some other mechanism that prevented things from breaking when they were included with glibc. In any case current versions of glibc would be broken by a change now. This type of interdependency is part of why I think the whole thing (trying to make kernel headers for stuf that's already defined in libc usable from userspace) was a bad idea to begin with. > Or ask kernel to stop using structures with userspace names. > This should not be that hard: > > struct __kernel_sockaddr_in {...} > #if __KERNEL__ > # define sockaddr_in __kernel_sockaddr_in > #endif Yes but then some patchup would be needed for uClibc and other libcs that actually want the kernel to define the structs. This would work better if the #define was in the other direction: # define __kernel_sockaddr_in sockaddr_in and done _before_ declaration of the structure, so that the actual struct tag would end up being the desired name in this case (both for kernel-internal and for uClibc, etc. use). Rich From vda.linux at googlemail.com Tue Oct 13 18:02:47 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 13 Oct 2015 20:02:47 +0200 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151013150525.GP8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> <20151013145335.GQ10551@port70.net> <20151013150525.GP8645@brightrain.aerifal.cx> Message-ID: On Tue, Oct 13, 2015 at 5:05 PM, Rich Felker wrote: >> > > This would address the case where the kernel header is included first, >> > > but it's not a case I or most of the musl community wants to support, >> > > because there's no guarantee that the kernel's definitions of these >> > > structures will actually be compatible with use elsewhere in the libc >> > > headers, etc. >> > >> > If kernel's definition does not match yours, there is a much >> > bigger problem than "includes do not compile": >> > kernel and userspace definitions of these structs *must* match >> > (modulo harmless things like different typedef names for field types). >> > >> > So in this case either kernel or libc would need to be fixed. >> >> why? >> >> in practice most types are c abi compatible with the kernel >> because translating the types at the syscall boundary is >> painful/impossible. >> >> but even with compatible binary representation there is >> plenty space for disagreement between kernel and libc on >> the source level. (of course code that includes both libc >> and kernel headers might not care about posix namespace >> violations or undefined behaviour in kernel headers..) >> >> and libc-compat does not cover all conflicting cases >> (i assume they just add workarouds when somebody hits >> a conflict), e.g. sys/inotify.h and linux/inotify.h are >> in conflict (and linux/inotify.h is not even standard c). > > Indeed the problem here is source compatibility, not binary > compatibility. Issues like names of types, choice of distinct types > that have the same size and representation but which are not > compatible types (which make problems if you take the address of the > member, including possibly aliasing problems which are real-world > bugs), etc. It's not that bad in practice. In C, typedefs are not new types. uint16_t, u16 and __u16 are all just aliases to "unsigned short". You won't get a conflict because different typedefs were used to declare a struct member whose address you are taking and passing to some function. If signedness and width match, then it will work without casts or compiler errors. From dalias at libc.org Tue Oct 13 18:56:22 2015 From: dalias at libc.org (Rich Felker) Date: Tue, 13 Oct 2015 14:56:22 -0400 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> <20151013145335.GQ10551@port70.net> <20151013150525.GP8645@brightrain.aerifal.cx> Message-ID: <20151013185622.GS8645@brightrain.aerifal.cx> On Tue, Oct 13, 2015 at 08:02:47PM +0200, Denys Vlasenko wrote: > On Tue, Oct 13, 2015 at 5:05 PM, Rich Felker wrote: > >> > > This would address the case where the kernel header is included first, > >> > > but it's not a case I or most of the musl community wants to support, > >> > > because there's no guarantee that the kernel's definitions of these > >> > > structures will actually be compatible with use elsewhere in the libc > >> > > headers, etc. > >> > > >> > If kernel's definition does not match yours, there is a much > >> > bigger problem than "includes do not compile": > >> > kernel and userspace definitions of these structs *must* match > >> > (modulo harmless things like different typedef names for field types). > >> > > >> > So in this case either kernel or libc would need to be fixed. > >> > >> why? > >> > >> in practice most types are c abi compatible with the kernel > >> because translating the types at the syscall boundary is > >> painful/impossible. > >> > >> but even with compatible binary representation there is > >> plenty space for disagreement between kernel and libc on > >> the source level. (of course code that includes both libc > >> and kernel headers might not care about posix namespace > >> violations or undefined behaviour in kernel headers..) > >> > >> and libc-compat does not cover all conflicting cases > >> (i assume they just add workarouds when somebody hits > >> a conflict), e.g. sys/inotify.h and linux/inotify.h are > >> in conflict (and linux/inotify.h is not even standard c). > > > > Indeed the problem here is source compatibility, not binary > > compatibility. Issues like names of types, choice of distinct types > > that have the same size and representation but which are not > > compatible types (which make problems if you take the address of the > > member, including possibly aliasing problems which are real-world > > bugs), etc. > > It's not that bad in practice. > > In C, typedefs are not new types. uint16_t, u16 and __u16 > are all just aliases to "unsigned short". > > You won't get a conflict because different typedefs > were used to declare a struct member whose address you are > taking and passing to some function. > If signedness and width match, then it will work without casts > or compiler errors. The problem is that u32 might be unsigned int or unsigned long (either possible on ILP32), u64 might be unsigned long or unsigned long long (either possible on LP64), etc. Also structs with different tags are distinct types. These are not ABI issues for machine-code object files but they are source-level compatibility issues and linking (arguably ABI) issues for LTO object files. They're also C++ issues; for instance it's possible that one translation unit declares a function taking a pointer to some network function without including the kernel header, and another defines it while including the kernel header, and the struct names or types mismatch (even in a layout-compatible way), the name mangling will be different and the code won't link. Rich From ibid.ag at gmail.com Tue Oct 13 21:55:34 2015 From: ibid.ag at gmail.com (Isaac Dunham) Date: Tue, 13 Oct 2015 14:55:34 -0700 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <20151013151048.GQ8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> <20151013151048.GQ8645@brightrain.aerifal.cx> Message-ID: <20151013215533.GA2073@newbook> On Tue, Oct 13, 2015 at 11:10:49AM -0400, Rich Felker wrote: > On Tue, Oct 13, 2015 at 02:10:24PM +0200, Denys Vlasenko wrote: > > > The other direction, suppressing kernel headers' definition of the > > > structs, is what we want to work, but they've restricted their logic > > > for that to only work when __GLIBC__ is defined. :( > > > > Yes, you will have to do by hand the thing which kernel > > automagically does for glibc - namely, define to 0: > > > > >> #undef __UAPI_DEF_SOCKADDR_IN > > >> /* tell kernel to not define the struct */ > > >> #define __UAPI_DEF_SOCKADDR_IN 0 > > >> #endif > > > > > We could do something like this but then we would need to keep up with > > > the list of all the __UAPI defines we need to suppress unwanted kernel > > > definitions. > > > > Looking at libc-compat.h, this list is at the moment only about > > 13 defines long: > > > > #define __UAPI_DEF_IN_ADDR 0 > > #define __UAPI_DEF_IN_IPPROTO 0 > > #define __UAPI_DEF_IN_PKTINFO 0 > > #define __UAPI_DEF_IP_MREQ 0 > > #define __UAPI_DEF_SOCKADDR_IN 0 > > #define __UAPI_DEF_IN_CLASS 0 > > #define __UAPI_DEF_IN6_ADDR 0 > > #define __UAPI_DEF_SOCKADDR_IN6 0 > > #define __UAPI_DEF_IPV6_MREQ 0 > > #define __UAPI_DEF_IPPROTO_V6 0 > > #define __UAPI_DEF_IPV6_OPTIONS 0 > > #define __UAPI_DEF_IN6_PKTINFO 0 > > #define __UAPI_DEF_IP6_MTUINFO 0 > > Thanks for making the list! For the time being I don't think it would > be too objectionable to simply define these in musl. Does anyone else > have an opinion on it? I'd like to see it for the time being, though long-term I still assume that the only real solution would be something like the proposed change in libc-compat.h: -#ifdef __GLIBC__ +#if defined(__GLIBC__) || defined(__UAPI_DONTNEED_DEFS) Thanks, Isaac Dunham From rob at landley.net Wed Oct 14 03:32:16 2015 From: rob at landley.net (Rob Landley) Date: Tue, 13 Oct 2015 22:32:16 -0500 Subject: [Aboriginal] Time for another release. In-Reply-To: References: <55B0650F.7020105@landley.net> Message-ID: <561DCCC0.9050306@landley.net> On 10/12/2015 07:00 PM, Denys Vlasenko wrote: > On Thu, Jul 23, 2015 at 5:52 AM, Rob Landley wrote: >> Bit past due, really. >> >> I got the sh2eb and sh2elf binflt toolchains working. Userspace isn't >> yet because nommu, I tried switching ash out for hush but it still needs >> fork(). > > No, hush definitely does not need fork(). > > It will use fork() if it _thinks_ it's being built for MMU machine. > > Set CONFIG_NOMMU=y to override that detection. Indeed, I found that a while back. (I thought it was autodetecting, it's not.) At the moment I've got some of the scripts depending on ELF2FLT and I need to switch that to "NOMMU=elf2flt" and "NOMMU=fdpic"... But now this release... Rob From nsz at port70.net Tue Oct 13 14:53:35 2015 From: nsz at port70.net (Szabolcs Nagy) Date: Tue, 13 Oct 2015 16:53:35 +0200 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> Message-ID: <20151013145335.GQ10551@port70.net> * Denys Vlasenko [2015-10-13 14:10:24 +0200]: > On Fri, Oct 9, 2015 at 9:46 PM, Rich Felker wrote: > >> Looking at kernel's libc-compat.h, it looks like you can get away > >> with using __UAPI_DEF_foo's like this? > >> > >> > >> #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1 > >> /* kernel already defined the struct, do nothing */ > >> #else > >> struct sockaddr_in { > >> ... > >> }; > > > > This would address the case where the kernel header is included first, > > but it's not a case I or most of the musl community wants to support, > > because there's no guarantee that the kernel's definitions of these > > structures will actually be compatible with use elsewhere in the libc > > headers, etc. > > If kernel's definition does not match yours, there is a much > bigger problem than "includes do not compile": > kernel and userspace definitions of these structs *must* match > (modulo harmless things like different typedef names for field types). > > So in this case either kernel or libc would need to be fixed. > why? in practice most types are c abi compatible with the kernel because translating the types at the syscall boundary is painful/impossible. but even with compatible binary representation there is plenty space for disagreement between kernel and libc on the source level. (of course code that includes both libc and kernel headers might not care about posix namespace violations or undefined behaviour in kernel headers..) and libc-compat does not cover all conflicting cases (i assume they just add workarouds when somebody hits a conflict), e.g. sys/inotify.h and linux/inotify.h are in conflict (and linux/inotify.h is not even standard c). From nsz at port70.net Tue Oct 6 11:01:58 2015 From: nsz at port70.net (Szabolcs Nagy) Date: Tue, 6 Oct 2015 13:01:58 +0200 Subject: [Aboriginal] [musl] Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] In-Reply-To: <561330C1.8070205@landley.net> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <561330C1.8070205@landley.net> Message-ID: <20151006110158.GM10551@port70.net> * Rob Landley [2015-10-05 21:24:01 -0500]: > On 10/05/2015 08:44 PM, Rich Felker wrote: > > On Mon, Oct 05, 2015 at 10:08:10AM -0500, Rob Landley wrote: > > The cleaner approach is just avoiding including both the kernel > > headers and libc/userspace headers for the same things in the same > > file. In theory this may be hard in some cases, but I find that I can > > almost always fix these sorts of errors during a build by commenting > > out one or two #include lines. > > I am _deeply_ curious how you'd get linux/loop.h on a platform where you > need the 32 bit loopback structure definition without including the > kernel header. I struggled with that one a lot back in the busybox days. in theory you can put all usage of the structure in a separate translation unit where you don't include any libc headers. (if you need libc api you can declare prototypes e.g. int ioctl(int, int,...); but if you need libc types there then you are in trouble). > (For the 64 bit version you can block copy the structure out of the > header into your program, just like you can block copy everything out of > headers and never actually #include anything, in the name of portability!) > > Sadly, the kernel headers are exported for a _reason_. If I need to > syscall something you haven't wrapped, I need the _NR_ and it varies per > target. It's a thing. > > Rob From vda.linux at googlemail.com Mon Oct 19 12:50:59 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 19 Oct 2015 14:50:59 +0200 Subject: [Aboriginal] Oy I am behind. In-Reply-To: <561C778E.2050404@landley.net> References: <55DD6D76.1090909@landley.net> <561C778E.2050404@landley.net> Message-ID: On Tue, Oct 13, 2015 at 5:16 AM, Rob Landley wrote: > On 10/12/2015 06:48 PM, Denys Vlasenko wrote: >> On Wed, Aug 26, 2015 at 9:40 AM, Rob Landley wrote: >>> And that's on top of the nommu support stuff I've been doing for $DAYJOB... >> >> Rob, please note that hush had a nommu bug discovered recently. > > Sigh. Ok, updating to current busybox. > >> Testcase is a bit convoluted: >> >> func() >> { >> while read p; do echo "$p"; done >> } >> pipe_to_func() >> { >> # We had a NOMMU bug which caused "echo Ok |" part to be lost >> echo Ok | func >> } >> pipe_to_func | cat >> echo $? >> >> And also, there is an embarrassing simple bug: "umask N" >> actually sets umask ~N. >> >> I released busybox-1.24.0 with both fixed. > > Updating broke > http://landley.net/hg/aboriginal/file/tip/sources/patches/busybox-ftpd.patch > which looks like it's still needed... Will go into 1.24.1 http://busybox.net/downloads/fixes-1.24.0/busybox-1.24.0-ftpd.patch From rob at landley.net Mon Oct 19 19:45:02 2015 From: rob at landley.net (Rob Landley) Date: Mon, 19 Oct 2015 14:45:02 -0500 Subject: [Aboriginal] Oy I am behind. In-Reply-To: References: <55DD6D76.1090909@landley.net> <561C778E.2050404@landley.net> Message-ID: <5625483E.6010209@landley.net> On 10/19/2015 07:50 AM, Denys Vlasenko wrote: > On Tue, Oct 13, 2015 at 5:16 AM, Rob Landley wrote: >> On 10/12/2015 06:48 PM, Denys Vlasenko wrote: >>> And also, there is an embarrassing simple bug: "umask N" >>> actually sets umask ~N. >>> >>> I released busybox-1.24.0 with both fixed. >> >> Updating broke >> http://landley.net/hg/aboriginal/file/tip/sources/patches/busybox-ftpd.patch >> which looks like it's still needed... > > Will go into 1.24.1 > > http://busybox.net/downloads/fixes-1.24.0/busybox-1.24.0-ftpd.patch Yay! I'm probably cutting an aboriginal release this coming weekend, if it's out by then I'll just upgrade to that. Thanks, Rob From vda.linux at googlemail.com Sat Oct 24 01:13:47 2015 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 24 Oct 2015 03:13:47 +0200 Subject: [Aboriginal] Oy I am behind. In-Reply-To: <5625483E.6010209@landley.net> References: <55DD6D76.1090909@landley.net> <561C778E.2050404@landley.net> <5625483E.6010209@landley.net> Message-ID: On Mon, Oct 19, 2015 at 9:45 PM, Rob Landley wrote: >> Will go into 1.24.1 >> >> http://busybox.net/downloads/fixes-1.24.0/busybox-1.24.0-ftpd.patch > > Yay! > > I'm probably cutting an aboriginal release this coming weekend, if it's > out by then I'll just upgrade to that. 1.24.1 is out. From rob at landley.net Sat Oct 24 12:52:35 2015 From: rob at landley.net (Rob Landley) Date: Sat, 24 Oct 2015 07:52:35 -0500 Subject: [Aboriginal] Oy I am behind. In-Reply-To: References: <55DD6D76.1090909@landley.net> <561C778E.2050404@landley.net> <5625483E.6010209@landley.net> Message-ID: <562B7F13.3020509@landley.net> On 10/23/2015 08:13 PM, Denys Vlasenko wrote: > On Mon, Oct 19, 2015 at 9:45 PM, Rob Landley wrote: >>> Will go into 1.24.1 >>> >>> http://busybox.net/downloads/fixes-1.24.0/busybox-1.24.0-ftpd.patch >> >> Yay! >> >> I'm probably cutting an aboriginal release this coming weekend, if it's >> out by then I'll just upgrade to that. > > 1.24.1 is out. Upgrade checked in. Still trying to fix a darn elf2flt issue over on the sh2eb target... Thanks, Rob From brendan.simon at etrix.com.au Fri Oct 30 01:07:33 2015 From: brendan.simon at etrix.com.au (Brendan Simon (eTRIX)) Date: Fri, 30 Oct 2015 12:07:33 +1100 Subject: [Aboriginal] Can Aboriginal Linux be used to create a Debian rootfs Message-ID: <5632C2D5.7090109@etrix.com.au> Hi. Just stumbled across Aboriginal Linux and it looks like an great project :) I am trying to create a Debian rootfs for an embedded system that uses Dual ARM A9 cores (Xilinx Zynq SoC). I'm currently trying to use multistrap (from the Emdebian project) and am now trying moved to brickstrap (a fork of polystrap which is a fork of multistrap). Brickstrap does everything in userspace via proot and uses QEMU for the final configuration phase. I was wondering if it is possible to use Aboriginal Linux to do some or all of this? i.e. create a Debian rootfs from debian binary packages. Would it be simpler? multistrap uses apt and can workout all the package dependencies, create a rootfs. That's why I like it. Is Aboriginal Linux capable of doing what I want? Is it ready or is it a way of supporting that kind of usage? Thanks, Brendan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri Oct 30 05:08:07 2015 From: rob at landley.net (Rob Landley) Date: Fri, 30 Oct 2015 00:08:07 -0500 Subject: [Aboriginal] Can Aboriginal Linux be used to create a Debian rootfs In-Reply-To: <5632C2D5.7090109@etrix.com.au> References: <5632C2D5.7090109@etrix.com.au> Message-ID: <5632FB37.4070907@landley.net> On 10/29/2015 08:07 PM, Brendan Simon (eTRIX) wrote: > Hi. Just stumbled across Aboriginal Linux and it looks like an great > project :) > > I am trying to create a Debian rootfs for an embedded system that uses > Dual ARM A9 cores (Xilinx Zynq SoC). > > I'm currently trying to use multistrap (from the Emdebian project) and > am now trying moved to brickstrap (a fork of polystrap which is a fork > of multistrap). Brickstrap does everything in userspace via proot and > uses QEMU for the final configuration phase. > > I was wondering if it is possible to use Aboriginal Linux to do some or > all of this? i.e. create a Debian rootfs from debian binary packages. > Would it be simpler? In theory, yes. In practice, it's a big todo item as explained here: http://landley.net/aboriginal/about.html#hairball For Debian I've been vaguely looking at: https://wiki.debian.org/HelmutGrohne/rebootstrap But haven't made a whole lot of progress. If I was sitting down to do it now, I'd try bootstrapping in a musl-libc build rather than a uClibc build but getting toybox to 1.0 is taking up my attention these days because this: http://landley.net/aboriginal/about.html#selfhost Turned into my CELF 2013 talk: outline: http://landley.net/talks/celf-2013.txt video: http://youtu.be/SGmtP5Lg_t0 Which led to: https://lwn.net/Articles/629362/ And now there's: http://www.theverge.com/2015/10/29/9639950/google-combining-android-chromeos-report So getting toybox to 1.0 is my highest priority todo item right now. That said, I'm working on an aboriginal linux release right now and hope to get it out this weekend. (I don't want to be _three_ kernel versions behind, that would be embarassing.) > multistrap uses apt and can workout all the package dependencies, create > a rootfs. That's why I like it. There's two ways to create a root filesystem: 1) Download source, compile, and install it. 2) Download prebuilt binaries and install them. Most of the distro bootstrapping I've tried doesn't cleanly separate these, they want some prebuilt binary packages (which aren't statically linked and depend on host libraries that aren't there). > Is Aboriginal Linux capable of doing what I want? > Is it ready or is it a way of supporting that kind of usage? I've built Linux From Scratch 6.8 under it, and even automated the process: http://landley.net/aboriginal/control-images (Although you might have to rebuild the control image from http://landley.net/hg/control-images because somebody sent me a bug report that their bootstrap was calling #!/bin/ash for something. I thought I'd fixed it when I switched to hush and uploaded the right binary, but maybe I missed something...) However, LFS 6.8 packages are too old to build with musl-libc, because they have #ifdef/#else staircases checking for specific library versions and they #error at the end if they can't recognize which libc you're running. I'm partway through an upgrade to LFS 7.7 but I'm kinda buried in todo items at the moment... Anyway, what the LFS builds shows is that the build environment is powerful enough to build debian, but the remaining problem is "can I build a debian chroot under gentoo or fedora". Using binary packages (basically untarring .deb files into a common directory), sure. Actually building them from source, the build scripts tend to have assumptions about what's already installed (as described on the hairball page). That said, if you actually try to do this, I'd be interested in participating. Post partial progress here and I can try to help debug... (Myself, I've never worked out how to set up my own debian repository so I can populate it with packages I built myself. That's an important step in creating a debian built with musl repo, let alone debian built with musl for sh4...) > Thanks, Brendan. Rob From rob at landley.net Fri Oct 30 09:52:02 2015 From: rob at landley.net (Rob Landley) Date: Fri, 30 Oct 2015 04:52:02 -0500 Subject: [Aboriginal] toybox sed screwing up libtool? Message-ID: <56333DC2.7050700@landley.net> So, on irc you reported a bug, and I tried to reproduce it: Build root-filesystem-i686, chroot into it with toolchain attached. So that's something like: tar xvzf root-filesystem-i686.tar.gz tar xvzf native-compiler-i686.tar.gz mv native-compiler-i686 root-filesystem-i686/usr/overlay chroot root-filesystem-i686 /sbin/init.sh sh /usr/overlay/init cd /home wget http://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz tar xvzf m4-1.4.17.tar.gz ./configure --prefix=/usr make make install cd .. wget http://ftp.gnu.org/gnu/libtool/libtool-2.4.6.tar.gz tar xvzf libtool-2.4.6.tar.gz cd libtool-2.4.6 ./configure --prefix=/usr make make install cd .. wget http://libarchive.org/downloads/libarchive-3.1.2.tar.gz cd libarchive-3.1.2 libtoolize --force --copy At this point, you said I should see: Somasis> `libtoolize --force --copy` alone seems to trigger the error sorry; the error is "libtoolize: error: AC_CONFIG_MACRO_DIRS([m4trace]) conflicts with ACLOCAL_AMFLAGS=-I build/autoconf." But what I did see is: # libtoolize --force --copy /bin/libtoolize: line 159: func_add_hook: command not found /bin/libtoolize: line 186: func_add_hook: command not found /bin/libtoolize: line 257: func_add_hook: command not found /bin/libtoolize: line 291: func_add_hook: command not found /bin/libtoolize: line 296: func_options: command not found /bin/libtoolize: line 1589: func_verbose: command not found And so on for several dozen pages... I have no idea what's wrong because I don't use libtool, ever, for anything. It was created to make non-elf systems behave like elf, and Linux has been ELF since 1996: http://lists.busybox.net/pipermail/uclibc/2007-June/038948.html So I don't know what success looks like here. Rob