Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On 11/10/20 6:02 PM, enh wrote: >> He can't tell you what your _objectives_ are, but if you want libc host >> compatibility domain expertise, that's the guy who knows where the bodies are >> buried. > > no, it's actually stuff like "non-Android keeps its list of users in > /etc/passwd" > > and "non-Android doesn't have a netd daemon that all DNS > queries should go via" and so on. Ah. That's the part Khem Raj gave annual tutorials about at ELC, dunno if he's kept current now he's working at Comcast. Ah, sorry, they're "Altria" now. My question is more "compatibility with what"? Neither sounds like it would hit hermetic builds, which run as a normal user (so aren't looking up a lot of UIDs, and you just said you got a patch for that one anyway) and all the source downloads should get handled by repo and then you can build in a netless container. It's not hermetic otherwise, or even reproducible. (Plus "static DNS doesn't work" is something glibc shares anyway, it tries to dlopen() helper libraries from a static context and hits the two heap problem. Static glibc would be "lateral progress", a thing I've railed about in the Linux world for years...) Trying it out in a fork to see what breaks doesn't seem like a bit lift, and you have the Giant Test Harness of Doom, but maybe I could try it here first... https://android.googlesource.com/platform/external/qemu/+/master/docs/PREBUILT-BINARIES.TXT Hmmm... ~/android/aosp$find . -name android-rebuild* ~/android/aosp$ Nope. *shrug* Project not staffed/funded is a song I know well, and "users show up making demands once a thing exists" is a thing. But static bionic is already in the NDK and I _have_ built binaries with it for a while now... > host bionic _is_ actually in use for some things already. it's just > not used for a wide _variety_ of tasks, so there are probably still > bits that don't work that just haven't been used yet. Exactly. But if "hermetic NDK build" is one of them, it's probably either toybox (send me the bug report, I fix) or the llvm suite (half of which you're using natively on target already)... I'd to poke at this more myself, but domain expertise aside when I can cycle back to regularly putting hours into toybox I need to finish toysh, cleanup and promote netlink-api route, and $DAYJOB needs stty, dhcp client, and sysvinit. Plus dd is just EMBARASSING. And THEN I need to glue the musl-cross-make native toolchains into the mkroot output and get LFS 10 to build under it, which needs AWK which is probably the largest remaining can of worms... Alas, if I try building new static toybox binaries with the NDK myself and swapping them in for the prebuilts to see if android builds, I couldn't properly test the result so all it would prove would be lack of build break. That's why AOSP still lives after Linux From Scratch in my todo heap: traversing the full LFS build is a simpler (and more easily penetrable) problem than the AOSP build. That said, if I get LFS working with mcm I could try it with a static NDK toybox build... :) Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On Tue, Nov 10, 2020 at 12:54 AM Rob Landley wrote: > > On 11/5/20 6:12 PM, enh wrote: > > On Mon, Nov 2, 2020 at 6:40 PM Rob Landley wrote: > >> > >> On 11/2/20 1:55 PM, enh wrote: > >>> On Fri, Oct 30, 2020 at 7:12 PM Rob Landley wrote: > On 10/28/20 7:06 PM, enh via Toybox wrote: > > One reason to use toybox on the host is to get the same behavior across > > Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one > > area where that doesn't quite work is that toybox uses the libc regular > > expression implementation. > > Which another reason the version of toybox you distribute should be > statically > linked against bionic. > >>> > >>> aye, but "host bionic" is a longer project with no-one funded to work on > >>> it. > >> > >> What's actually involved? Mostly seems to be switching back to a minimal > >> _start? > >> > >> If there _is_ anything missing you care about (ls -l showing usernames?) > >> then > >> license-wise, you should be able to pull anything you need from musl... > > > > funnily enough, someone just merged a patch to read /etc/passwd and > > /etc/group if we're not on device (the device uses the usual format, > > but has multiple different locations so that SoC vendors and OEMs and > > the core platform all get their own file on their own partition). > > > > the order zero problem is that i don't think anyone has the full list > > of what needs to be done. > > Rich Felker wrote a C library from scratch. He started working on it back > when I > was still busybox maintainer, and our IRC conversation about actually > releasing > it as a project and licensing it was... 2012 I think? Yeah, he objected to my > flounce https://landley.net/notes-2012.html#18-01-2012 and wanted to know why > I > cared so much (which was only 2 months after > https://landley.net/notes-2011.html#13-11-2011 so I had links ready, including > https://landley.net/notes-2010.html#19-07-2010). > > Rich actually worked to get _binary_ compatability with glibc to run things > like > the flash plugin. It's not perfect, but he's gone pretty deeply into this area > and has more domain expertise than a lot of the glibc guys (who never went > back > and analyzed their own stuff the same way). > > He can't tell you what your _objectives_ are, but if you want libc host > compatibility domain expertise, that's the guy who knows where the bodies are > buried. no, it's actually stuff like "non-Android keeps its list of users in /etc/passwd" and "non-Android doesn't have a netd daemon that all DNS queries should go via" and so on. host bionic _is_ actually in use for some things already. it's just not used for a wide _variety_ of tasks, so there are probably still bits that don't work that just haven't been used yet. > > That's fine, and mostly what users want, but > > those folks trying to get the exact same behavior everywhere might want > > to switch in a known regex implementation (bionic's NetBSD regex > > implementation, say) for increased consistency. > > By statically linking the binaries against bionic. :) > > (Did you ever fix the "hello world segfaults in a chroot that doesn't > have > /dev/null because bionic's _start code does a lot with no error > checking" issue? > >>> > >>> no, that's actually a deliberate crash. that's definitely not a > >>> supported _device_ configuration, and we deliberately minimize the > >>> differences between host and device. (it's 99% of the point of having > >>> host bionic in the first place!) > >> > >> Meaning you can't link PID 1 against bionic unless you have a static /dev, > >> and > >> the kernel guys keep rejecting my "make initramfs honor > >> CONFIG_DEVTMPFS_MOUNT" > >> patch. Sigh, I need to teach toybox cpio to accept non-filesystem > >> metadata. It's > >> on the todo list... > > > > if this actually causes trouble for the hermetic build or GCE types we > > can think about relaxing it, but i'm not aware of anyone [other than > > Android, which _wants_ a static /dev] using bionic for init. > > scripts/mkroot.sh in the toybox build creates a qemu-bootable Linux system > with > toybox defconfig as initramfs. (Ok, defconfig + route + sh, but I'm working to > get both promoted into defconfig.) You can chroot into the result, or > qemu-*.sh > in the directory to launch qemu with /dev/console connected the stdin/stdout > of > qemu. > > I test that with the host libc and with the musl-cross-make toolchains for a > bunch of targets, but if I do it with the NDK the result immediately segfaults > no matter what binary I run, because /dev is empty. The reason /dev is empty > is > the build runs as a normal user (I can't mknod without root access) and I > haven't taught toybox cpio to read the linux cpio generation text format yet. > (It's on the todo list.) > > I want the initramfs to be external rather than statically linked into the > kernel because then I
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On 11/5/20 6:12 PM, enh wrote: > On Mon, Nov 2, 2020 at 6:40 PM Rob Landley wrote: >> >> On 11/2/20 1:55 PM, enh wrote: >>> On Fri, Oct 30, 2020 at 7:12 PM Rob Landley wrote: On 10/28/20 7:06 PM, enh via Toybox wrote: > One reason to use toybox on the host is to get the same behavior across > Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one > area where that doesn't quite work is that toybox uses the libc regular > expression implementation. Which another reason the version of toybox you distribute should be statically linked against bionic. >>> >>> aye, but "host bionic" is a longer project with no-one funded to work on it. >> >> What's actually involved? Mostly seems to be switching back to a minimal >> _start? >> >> If there _is_ anything missing you care about (ls -l showing usernames?) then >> license-wise, you should be able to pull anything you need from musl... > > funnily enough, someone just merged a patch to read /etc/passwd and > /etc/group if we're not on device (the device uses the usual format, > but has multiple different locations so that SoC vendors and OEMs and > the core platform all get their own file on their own partition). > > the order zero problem is that i don't think anyone has the full list > of what needs to be done. Rich Felker wrote a C library from scratch. He started working on it back when I was still busybox maintainer, and our IRC conversation about actually releasing it as a project and licensing it was... 2012 I think? Yeah, he objected to my flounce https://landley.net/notes-2012.html#18-01-2012 and wanted to know why I cared so much (which was only 2 months after https://landley.net/notes-2011.html#13-11-2011 so I had links ready, including https://landley.net/notes-2010.html#19-07-2010). Rich actually worked to get _binary_ compatability with glibc to run things like the flash plugin. It's not perfect, but he's gone pretty deeply into this area and has more domain expertise than a lot of the glibc guys (who never went back and analyzed their own stuff the same way). He can't tell you what your _objectives_ are, but if you want libc host compatibility domain expertise, that's the guy who knows where the bodies are buried. > That's fine, and mostly what users want, but > those folks trying to get the exact same behavior everywhere might want > to switch in a known regex implementation (bionic's NetBSD regex > implementation, say) for increased consistency. By statically linking the binaries against bionic. :) (Did you ever fix the "hello world segfaults in a chroot that doesn't have /dev/null because bionic's _start code does a lot with no error checking" issue? >>> >>> no, that's actually a deliberate crash. that's definitely not a >>> supported _device_ configuration, and we deliberately minimize the >>> differences between host and device. (it's 99% of the point of having >>> host bionic in the first place!) >> >> Meaning you can't link PID 1 against bionic unless you have a static /dev, >> and >> the kernel guys keep rejecting my "make initramfs honor >> CONFIG_DEVTMPFS_MOUNT" >> patch. Sigh, I need to teach toybox cpio to accept non-filesystem metadata. >> It's >> on the todo list... > > if this actually causes trouble for the hermetic build or GCE types we > can think about relaxing it, but i'm not aware of anyone [other than > Android, which _wants_ a static /dev] using bionic for init. scripts/mkroot.sh in the toybox build creates a qemu-bootable Linux system with toybox defconfig as initramfs. (Ok, defconfig + route + sh, but I'm working to get both promoted into defconfig.) You can chroot into the result, or qemu-*.sh in the directory to launch qemu with /dev/console connected the stdin/stdout of qemu. I test that with the host libc and with the musl-cross-make toolchains for a bunch of targets, but if I do it with the NDK the result immediately segfaults no matter what binary I run, because /dev is empty. The reason /dev is empty is the build runs as a normal user (I can't mknod without root access) and I haven't taught toybox cpio to read the linux cpio generation text format yet. (It's on the todo list.) I want the initramfs to be external rather than statically linked into the kernel because then I can replace it without rebuilding the kernel, and other people can easily extract it or plug it into _their_ kernels. > That actually works pretty well, but portability.h has an #ifndef test > for REG_STARTEND before including that gets in the way. To > make up for that, this patch removes the unnecessary #include > from grep.c itself. Applied, but it's one measure of a whack-a-mole problem space. >>> >>> there's never going to be a "host bionic for macOS" anyway, so this is >>> necessary if not sufficient. >> >> Statically linking on macos seems less of a minefield, though? They ship >> libtool >>
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On Mon, Nov 2, 2020 at 6:40 PM Rob Landley wrote: > > On 11/2/20 1:55 PM, enh wrote: > > On Fri, Oct 30, 2020 at 7:12 PM Rob Landley wrote: > >> On 10/28/20 7:06 PM, enh via Toybox wrote: > >>> One reason to use toybox on the host is to get the same behavior across > >>> Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one > >>> area where that doesn't quite work is that toybox uses the libc regular > >>> expression implementation. > >> > >> Which another reason the version of toybox you distribute should be > >> statically > >> linked against bionic. > > > > aye, but "host bionic" is a longer project with no-one funded to work on it. > > What's actually involved? Mostly seems to be switching back to a minimal > _start? > > If there _is_ anything missing you care about (ls -l showing usernames?) then > license-wise, you should be able to pull anything you need from musl... funnily enough, someone just merged a patch to read /etc/passwd and /etc/group if we're not on device (the device uses the usual format, but has multiple different locations so that SoC vendors and OEMs and the core platform all get their own file on their own partition). the order zero problem is that i don't think anyone has the full list of what needs to be done. > >>> That's fine, and mostly what users want, but > >>> those folks trying to get the exact same behavior everywhere might want > >>> to switch in a known regex implementation (bionic's NetBSD regex > >>> implementation, say) for increased consistency. > >> > >> By statically linking the binaries against bionic. :) > >> > >> (Did you ever fix the "hello world segfaults in a chroot that doesn't have > >> /dev/null because bionic's _start code does a lot with no error checking" > >> issue? > > > > no, that's actually a deliberate crash. that's definitely not a > > supported _device_ configuration, and we deliberately minimize the > > differences between host and device. (it's 99% of the point of having > > host bionic in the first place!) > > Meaning you can't link PID 1 against bionic unless you have a static /dev, and > the kernel guys keep rejecting my "make initramfs honor CONFIG_DEVTMPFS_MOUNT" > patch. Sigh, I need to teach toybox cpio to accept non-filesystem metadata. > It's > on the todo list... if this actually causes trouble for the hermetic build or GCE types we can think about relaxing it, but i'm not aware of anyone [other than Android, which _wants_ a static /dev] using bionic for init. > >>> That actually works pretty well, but portability.h has an #ifndef test > >>> for REG_STARTEND before including that gets in the way. To > >>> make up for that, this patch removes the unnecessary #include > >>> from grep.c itself. > >> > >> Applied, but it's one measure of a whack-a-mole problem space. > > > > there's never going to be a "host bionic for macOS" anyway, so this is > > necessary if not sufficient. > > Statically linking on macos seems less of a minefield, though? They ship > libtool > (which has nothing to do with gnu libtool, it's a combined ar+ranlib from > next) > and it just works? yeah, but the problem we're trying to solve here is "same regular expression implementation", not "static binary" :-) > Glibc is uniquely broken because Ulrich Drepper personally hated static > linking > (https://www.akkadia.org/drepper/no_static_linking.html) and intentionally > sabotaged it (moving things like name resolution behind dlopen), and when the > egcs guys... sorry, the eglibc guys were lured back into the fold and put > another committee in charge of the project instead of a maintainer (so nobody > would have authority to complain about the FSF (such as Drepper's polemic > against Stallman starting with "And now some not so nice things" in > https://sourceware.org/legacy-ml/libc-announce/2001/msg0.html), the > committee was intentionally organized to be unable to tackle any remotely > political issues, and thus couldn't undo Drepper's anti-static prejudice > without > admitting a mistake had been made by "the project". So they've been throwing > good code after bad ever since, and glibc is uniquely insane and broken as a > result. (Which means people have been inventing crap like "snap" and "flatpak" > so they can statically link dynamically linked programs by bundling up the > resulting filesystem and loopback mounting it in a container. Sigh. It's like > watching people build redstone computers in minecraft.) > > Musl isn't broken that way, and neither is macos. I thought the point of host > bionic (other than behaving the same everywhere so catching bugs early and > avoiding potential distro skew and thus build dependencies for where the AOSP > prebuilts get updated from) is to avoid glibc's intentional sabotage of static > linking. depends on who's asking. although there's no team blocked on not having host bionic, there are several teams for whom it might be useful. some of them for one reason, some the other, and some
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On 11/2/20 1:55 PM, enh wrote: > On Fri, Oct 30, 2020 at 7:12 PM Rob Landley wrote: >> On 10/28/20 7:06 PM, enh via Toybox wrote: >>> One reason to use toybox on the host is to get the same behavior across >>> Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one >>> area where that doesn't quite work is that toybox uses the libc regular >>> expression implementation. >> >> Which another reason the version of toybox you distribute should be >> statically >> linked against bionic. > > aye, but "host bionic" is a longer project with no-one funded to work on it. What's actually involved? Mostly seems to be switching back to a minimal _start? If there _is_ anything missing you care about (ls -l showing usernames?) then license-wise, you should be able to pull anything you need from musl... >>> That's fine, and mostly what users want, but >>> those folks trying to get the exact same behavior everywhere might want >>> to switch in a known regex implementation (bionic's NetBSD regex >>> implementation, say) for increased consistency. >> >> By statically linking the binaries against bionic. :) >> >> (Did you ever fix the "hello world segfaults in a chroot that doesn't have >> /dev/null because bionic's _start code does a lot with no error checking" >> issue? > > no, that's actually a deliberate crash. that's definitely not a > supported _device_ configuration, and we deliberately minimize the > differences between host and device. (it's 99% of the point of having > host bionic in the first place!) Meaning you can't link PID 1 against bionic unless you have a static /dev, and the kernel guys keep rejecting my "make initramfs honor CONFIG_DEVTMPFS_MOUNT" patch. Sigh, I need to teach toybox cpio to accept non-filesystem metadata. It's on the todo list... >>> That actually works pretty well, but portability.h has an #ifndef test >>> for REG_STARTEND before including that gets in the way. To >>> make up for that, this patch removes the unnecessary #include >>> from grep.c itself. >> >> Applied, but it's one measure of a whack-a-mole problem space. > > there's never going to be a "host bionic for macOS" anyway, so this is > necessary if not sufficient. Statically linking on macos seems less of a minefield, though? They ship libtool (which has nothing to do with gnu libtool, it's a combined ar+ranlib from next) and it just works? Glibc is uniquely broken because Ulrich Drepper personally hated static linking (https://www.akkadia.org/drepper/no_static_linking.html) and intentionally sabotaged it (moving things like name resolution behind dlopen), and when the egcs guys... sorry, the eglibc guys were lured back into the fold and put another committee in charge of the project instead of a maintainer (so nobody would have authority to complain about the FSF (such as Drepper's polemic against Stallman starting with "And now some not so nice things" in https://sourceware.org/legacy-ml/libc-announce/2001/msg0.html), the committee was intentionally organized to be unable to tackle any remotely political issues, and thus couldn't undo Drepper's anti-static prejudice without admitting a mistake had been made by "the project". So they've been throwing good code after bad ever since, and glibc is uniquely insane and broken as a result. (Which means people have been inventing crap like "snap" and "flatpak" so they can statically link dynamically linked programs by bundling up the resulting filesystem and loopback mounting it in a container. Sigh. It's like watching people build redstone computers in minecraft.) Musl isn't broken that way, and neither is macos. I thought the point of host bionic (other than behaving the same everywhere so catching bugs early and avoiding potential distro skew and thus build dependencies for where the AOSP prebuilts get updated from) is to avoid glibc's intentional sabotage of static linking. > unfortunately, something (presumably a kernel or file system change) > seems to have broken a dd test on cuttlefish, so that's the next thing > i need to look at when i can find some time: > > FAIL: dd sync,noerror > echo -ne "I WANT\n" > input > echo -ne '' | dd if=input of=outFile seek=8860 bs=1M conv=sync,noerror > 2>/dev/null && >stat -c "%s" outFile && rm -f outFile > --- expected 2020-10-29 16:10:58.647991948 -0500 > +++ actual 2020-10-29 16:10:58.667991947 -0500 > @@ -1 +1 @@ > -9291431936 > +701497344 I _really_ need to make a (5th?) attempt to clean up dd. But not until I can carve out 2 uninterrupted weeks for it. Maybe new year's? I specced out the block repacking layer it needs to insulate itself from that sort of thing _years_ ago, and just... my todo list runneth over. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On Fri, Oct 30, 2020 at 7:12 PM Rob Landley wrote: > > > > On 10/28/20 7:06 PM, enh via Toybox wrote: > > One reason to use toybox on the host is to get the same behavior across > > Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one > > area where that doesn't quite work is that toybox uses the libc regular > > expression implementation. > > Which another reason the version of toybox you distribute should be statically > linked against bionic. aye, but "host bionic" is a longer project with no-one funded to work on it. > > That's fine, and mostly what users want, but > > those folks trying to get the exact same behavior everywhere might want > > to switch in a known regex implementation (bionic's NetBSD regex > > implementation, say) for increased consistency. > > By statically linking the binaries against bionic. :) > > (Did you ever fix the "hello world segfaults in a chroot that doesn't have > /dev/null because bionic's _start code does a lot with no error checking" > issue? no, that's actually a deliberate crash. that's definitely not a supported _device_ configuration, and we deliberately minimize the differences between host and device. (it's 99% of the point of having host bionic in the first place!) > > That actually works pretty well, but portability.h has an #ifndef test > > for REG_STARTEND before including that gets in the way. To > > make up for that, this patch removes the unnecessary #include > > from grep.c itself. > > Applied, but it's one measure of a whack-a-mole problem space. there's never going to be a "host bionic for macOS" anyway, so this is necessary if not sufficient. unfortunately, something (presumably a kernel or file system change) seems to have broken a dd test on cuttlefish, so that's the next thing i need to look at when i can find some time: FAIL: dd sync,noerror echo -ne "I WANT\n" > input echo -ne '' | dd if=input of=outFile seek=8860 bs=1M conv=sync,noerror 2>/dev/null && stat -c "%s" outFile && rm -f outFile --- expected 2020-10-29 16:10:58.647991948 -0500 +++ actual 2020-10-29 16:10:58.667991947 -0500 @@ -1 +1 @@ -9291431936 +701497344 > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [PATCH] Make it easier to switch regex implementations.
On 10/28/20 7:06 PM, enh via Toybox wrote: > One reason to use toybox on the host is to get the same behavior across > Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one > area where that doesn't quite work is that toybox uses the libc regular > expression implementation. Which another reason the version of toybox you distribute should be statically linked against bionic. > That's fine, and mostly what users want, but > those folks trying to get the exact same behavior everywhere might want > to switch in a known regex implementation (bionic's NetBSD regex > implementation, say) for increased consistency. By statically linking the binaries against bionic. :) (Did you ever fix the "hello world segfaults in a chroot that doesn't have /dev/null because bionic's _start code does a lot with no error checking" issue? > That actually works pretty well, but portability.h has an #ifndef test > for REG_STARTEND before including that gets in the way. To > make up for that, this patch removes the unnecessary #include > from grep.c itself. Applied, but it's one measure of a whack-a-mole problem space. Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] [PATCH] Make it easier to switch regex implementations.
One reason to use toybox on the host is to get the same behavior across Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one area where that doesn't quite work is that toybox uses the libc regular expression implementation. That's fine, and mostly what users want, but those folks trying to get the exact same behavior everywhere might want to switch in a known regex implementation (bionic's NetBSD regex implementation, say) for increased consistency. That actually works pretty well, but portability.h has an #ifndef test for REG_STARTEND before including that gets in the way. To make up for that, this patch removes the unnecessary #include from grep.c itself. --- lib/portability.h | 1 + toys/posix/grep.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) From a9a1734cab78f5a44e8c098b1b4f21ffe5ec58dd Mon Sep 17 00:00:00 2001 From: Elliott Hughes Date: Wed, 28 Oct 2020 16:48:14 -0700 Subject: [PATCH] Make it easier to switch regex implementations. One reason to use toybox on the host is to get the same behavior across Android/Linux/macOS. Unfortunately (as we've seen from a few bugs) one area where that doesn't quite work is that toybox uses the libc regular expression implementation. That's fine, and mostly what users want, but those folks trying to get the exact same behavior everywhere might want to switch in a known regex implementation (bionic's NetBSD regex implementation, say) for increased consistency. That actually works pretty well, but portability.h has an #ifndef test for REG_STARTEND before including that gets in the way. To make up for that, this patch removes the unnecessary #include from grep.c itself. --- lib/portability.h | 1 + toys/posix/grep.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/portability.h b/lib/portability.h index acc32fd4..05a449ee 100644 --- a/lib/portability.h +++ b/lib/portability.h @@ -6,6 +6,7 @@ // For musl #define _ALL_SOURCE +#include #ifndef REG_STARTEND #define REG_STARTEND 0 #endif diff --git a/toys/posix/grep.c b/toys/posix/grep.c index 1fa1a7c4..9f445fca 100644 --- a/toys/posix/grep.c +++ b/toys/posix/grep.c @@ -65,7 +65,6 @@ config FGREP #define FOR_grep #include "toys.h" -#include GLOBALS( long m, A, B, C; -- 2.29.1.341.ge80a0c044ae-goog ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
