On 05/31/2016 06:33 PM, Felix Janda wrote: > Just commenting on this: > > Rob Landley wrote: >> As for the lib/portability.h patch: FreeBSD doesn't have features.h, but >> Linux and MacOS X agree on that one? Odd. Speaking of which, we have >> __FreeBSD__ without #including features.h? > > The compiler might define it similarly to how it defines __linux__. > >> As for this bit: >> >> -#if !defined(__GLIBC__) && !defined(__BIONIC__) >> +#if !defined(__GLIBC__) && !defined(__BIONIC__) && !defined(__FreeBSD__) >> >> If we didn't include features.h, we shouldn't have __GLIBC__ or >> __BIONIC__ #defined because that's the header that defines them. I'd >> also assume that if we're building on freebsd, we don't have those >> #defined either because it's got its own libc? So why add a __FreeBSD__ >> guard symbol here? > > For glibc it seems to me, that almost any header will include > <features.h>. So including <sys/types.h> is presumably enough to get > the definition of _GLIBC_. It might also work for the other systems > targetted by portability.h.
In which case you _do_ have glibc...? > Felix > > PS: Just to mention, there is also something called kfreebsd [1], which > will define both _GLIBC_ and __FreeBSD__ (but not __linux__). > > [1]: http://www.debian.org/ports/kfreebsd-gnu Again, you would _have_ glibc. That's what it's testing for. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
