[Toybox] Fwd: [t2] GCC 9 breaks compilation of glibc
Rob, this may also have an effect in toybox, ?maybe? Forwarded Message Subject: [t2] GCC 9 breaks compilation of glibc Date: Tue, 7 May 2019 10:37:59 +0200 From: Frits Letteboer To: T2 developers mailing list Source: https://gitlab.gnome.org/GNOME/glib/merge_requests/626 ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] pathological case in sed s///g
On Mon, May 06, 2019 at 10:57:23PM -0700, enh wrote: > > I know not everything is a macro that can be tested; both myself and > > folks from other implementations are interested in developing an > > agreed-upon way to report availability of other extensions via macros, > > so that configure-style compile/link tests are not needed. This would > > also facilitate reporting of some things that can't even properly be > > tested because they would need runtime tests. Unfortunately efforts in > > this area are stalled from lack of interest. If you or others would > > like to raise a fuss about making it happen, I'd welcome it. > > wouldn't it be better to have more stuff along the lines of clang's > __has_builtin/__has_feature/__has_include? they're already very useful > for getting rid of this kind of stuff, and a __has_function would > cover most of what's missing. It probably doesn't, and it's hard to figure out who would be responsible for providing them. Are you suggesting the compiler would do it automatically based on presence of a declaration? There's already an evil hack to check for presence of a declaration and branch on the result using _Generic, but of course that's after the preprocessor level. OTOH the preprocessor doesn't and can't have access to the presence or absence of declarations since everything is just tokens at that stage. I think it would be a lot simpler, more flexible, and compatible with existing compilers (probably a requirement on our side) to simply have the library define macros for the individual extensions or extension groups it provides -- basically the same thing as the existing POSIX macros in unistd.h, but for extensions outside of POSIX. One major advantage here is that we can also report extensions that are not in the form of symbols or flags, but some other type of interface -- for example, support for %m in the printf family. As a side benefit, this would probably require us to look at, enumerate, and better document the extensions we support. :-) Rich ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] pathological case in sed s///g
On Tue, May 07, 2019 at 05:27:24PM +0300, makep...@firemail.cc wrote: > > > wouldn't it be better to have more stuff along the lines of clang's > > __has_builtin/__has_feature/__has_include? they're already very useful > > for getting rid of this kind of stuff, and a __has_function would > > cover most of what's missing. > > Feature claims of clang and musl are giving us a conflict when > building cmake btw, could anyone look at > https://github.com/gentoo/musl/issues/141 please? I don't know > whether to forward this to clang or musl or cmake or some other > list, thus glad you brought up the topic. Just replied on the tracker: "musl uses a BSD style header layout, where the system (libc) header location must come before the compiler's header location in the search path; it does not use and is not compatible with the compiler-provided versions of the standard headers, which should never get included." Thanks for the heads-up. Rich ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] pathological case in sed s///g
> wouldn't it be better to have more stuff along the lines of clang's > __has_builtin/__has_feature/__has_include? they're already very useful > for getting rid of this kind of stuff, and a __has_function would > cover most of what's missing. Feature claims of clang and musl are giving us a conflict when building cmake btw, could anyone look at https://github.com/gentoo/musl/issues/141 please? I don't know whether to forward this to clang or musl or cmake or some other list, thus glad you brought up the topic. ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] GNU tar sparse files
On 5/1/19 1:12 PM, Rob Landley wrote: > On 4/30/19 10:59 AM, enh via Toybox wrote: >> there's a tar file checked in to AOSP that causes trouble for toybox >> tar. you can find it (and the script that generates it) here: >> >> https://android.googlesource.com/platform/system/update_engine/+/refs/heads/master/sample_images/ > > Adding support for sparse files is on my todo list, I just waited for a user > to > crop up. Lemme see what I can do... > > (Hmmm, we already truncate the file when --overwrite (and O_EXCL otherwise, > AHA > bug if O_EXCL fails we don't skippy() when we didn't sendfile(), this is why > proper testing includes ALL THE ERROR PATHS, grrr...) > > Ahem. Working on it... Ok, having run rather a lot of tests, S headers don't seem to use the "prefix" field to store a prefix at all, even if putting the prefix in the leftover space would make a long name fit in the "name" field. This is despite the fact that the sparse offset/data list starts at 386 bytes into the header and the prefix starts at 345, it just skips 41 bytes for no readily apparent reason? Each word pair is 12+1+12+1=26 bytes, they could fit another pair in but _don't_. (In fact if they wanted to go to the full 512 they could fit in 6 pairs instead of 4.) The aristocrats FSF! Anyway, the follow it with a "more is expected" flag (0 or 1), and then the total sparse file's reported length (the length in the S record's length field is the stored data length, this is apparently for sanity checking?) When more is expected is set it's followed by a header that's just offset/length pairs (up to 21 of them), with another more is expected flag at 504. (This isn't a proper header, no "ustar" or record type or anything, you know because of the previous header.) And then after the first one without a more is expected flag, the data (which you chop up yourself based on the offset/length array). Easy enough to make it read them. Slightly fiddlier to make it write them (gotta do two passes with SEEK_HOLE). Oh, and the data they put in adds a hole of size zero at the end of the file, which seems completely unnecessary but if I'm still going for binary compatibility with the other thing's output... And I still need to teach lib/args.c to allow "tar --sparse cf blah.tgz filename" don't I? Tomorrow is 3 months from the last release... Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
