compatability: heirloom-utils +.5, libarchive -1

compatability: heirloom-utils +.5, libarchive -1

[Isaac Dunham]

I was building a kernel on Sabotage Linux (I'm using a rather modified
version already...), with initramfs enabled (which Sabotage does not
seem to support).  make would die because it couldn't find a cpio.xz
archive, so I assumed I needed a full cpio and xz.
That wasn't the issue, but I found some more compatability stuff:
xz: Seems to build fine (well, selecting {en,de}coders may not work
right, but otherwise it builds unchanged)
heirloom-utils: They are trying to support other nonstandard linux
libcs, so they check for __GLIBC__ | __uclibc__ to determine whether
dirent.h is present & sufficient; if dietlibc is detected, both
unistd.h & dirent.h are used.  The fallback is sys/dirent.h This should
probably be __linux__ | _POSIX_SOURCE triggers dirent.h inclusion, then
__diet__ triggers unistd.h; but if libc5/newlib are nonconformant here,
then that logic would be inadequate.
libarchive: needs memory.h --I just dropped it, since the syntax isn't
exactly like string.h, and there are at least two other cpio
implementations

Also, could PATH_MAX be exported unconditionally, or is that
nonstandard? Currently, defining any of the standard compatability
macros enables it.
This is needed for the kernel to build without defining HOSTCFLAGS,
though it really wants -D_GNU_SOURCE

Isaac

Re: compatability: heirloom-utils +.5, libarchive -1

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2012-01-03 06:06:00 -0800]:
> heirloom-utils: They are trying to support other nonstandard linux
> libcs, so they check for __GLIBC__ | __uclibc__ to determine whether
> dirent.h is present & sufficient; if dietlibc is detected, both
> unistd.h & dirent.h are used.  The fallback is sys/dirent.h This should
> probably be __linux__ | _POSIX_SOURCE triggers dirent.h inclusion, then
> __diet__ triggers unistd.h; but if libc5/newlib are nonconformant here,
> then that logic would be inadequate.

i had to fix things in heirloom to be able to compile
it with pcc+musl
i did about the same hacks, but then i ran various tests
and some of the more obscure tools failed so i figured
heirloom is not that good quality, eg.:
nl -b a -v 0
(i would never use nl but it turns out the build
script mess of dash does ..for whatever reason)

> Also, could PATH_MAX be exported unconditionally, or is that
> nonstandard? Currently, defining any of the standard compatability
> macros enables it.

i think you cannot export it unconditionally

PATH_MAX is in limits.h which is also specified by iso c
so you cannot just export it if posix is not required
explicitly

> This is needed for the kernel to build without defining HOSTCFLAGS,
> though it really wants -D_GNU_SOURCE
> 
> Isaac

Re: compatability: heirloom-utils +.5, libarchive -1

[Rich Felker]

On Tue, Jan 03, 2012 at 06:06:00AM -0800, Isaac Dunham wrote:
> I was building a kernel on Sabotage Linux (I'm using a rather modified
> version already...), with initramfs enabled (which Sabotage does not
> seem to support).  make would die because it couldn't find a cpio.xz
> archive, so I assumed I needed a full cpio and xz.
> That wasn't the issue, but I found some more compatability stuff:
> xz: Seems to build fine (well, selecting {en,de}coders may not work
> right, but otherwise it builds unchanged)
> heirloom-utils: They are trying to support other nonstandard linux
> libcs, so they check for __GLIBC__ | __uclibc__ to determine whether
> dirent.h is present & sufficient; if dietlibc is detected, both

This sort of test is really backwards. The correct approach is to test
conditionally for the (small, finite) set of known-broken libs (diet,
etc.) and otherwise assume a working, conformant system.

> libarchive: needs memory.h --I just dropped it, since the syntax isn't
> exactly like string.h, and there are at least two other cpio
> implementations

Yes, memory.h is purely a nonstandard alias for string.h.

> Also, could PATH_MAX be exported unconditionally, or is that
> nonstandard? Currently, defining any of the standard compatability
> macros enables it.
> This is needed for the kernel to build without defining HOSTCFLAGS,
> though it really wants -D_GNU_SOURCE

I suspect there are other warnings that should really be errors when
you try building without HOSTCFLAGS, and which might break on 64-bit
systems due to int/pointer size mismatch. You really need to define
the right feature-test macros for what it needs.

Rich

Re: compatability: heirloom-utils +.5, libarchive -1

[Isaac Dunham]

On Tue, 3 Jan 2012 18:38:08 +0100
Szabolcs Nagy <nsz@port70.net> wrote:
> i had to fix things in heirloom to be able to compile
> it with pcc+musl
> i did about the same hacks, but then i ran various tests
> and some of the more obscure tools failed so i figured
> heirloom is not that good quality, eg.:
> nl -b a -v 0
> (i would never use nl but it turns out the build
> script mess of dash does ..for whatever reason)
heirloom toolchest has about four "personalities":
1. SVRx (default?)
2. BSD
3. Single UNIX 3
4. SUS
(The latter two are variants of POSIX)
In general, the POSIX variants are about as close to precisely
standards-conformant as you can get; unfortunately, the plain old UNIX
versions are default. I note, though, that nl presumably ought to start
numbering at 0 when specified; instead, it starts at 1 (SU3/SUS
variants), skipping the line that would be numbered 0.  The old unix
version apparently didn't recognize -b.
But I figure it beats Busybox any day--and I'd rather not use GNU
bloat.

I'd rather use mksh/ksh93, but if you want a POSIX shell, the Bourne
shell beats dash on standards-conformance (after all, it *is* the
standard). mksh (when invoked as sh) is almost pure POSIX.

Isaac

Re: compatability: heirloom-utils +.5, libarchive -1

[Rich Felker]

On Wed, Jan 04, 2012 at 06:05:26PM -0800, Isaac Dunham wrote:
> On Tue, 3 Jan 2012 18:38:08 +0100
> Szabolcs Nagy <nsz@port70.net> wrote:
> > i had to fix things in heirloom to be able to compile
> > it with pcc+musl
> > i did about the same hacks, but then i ran various tests
> > and some of the more obscure tools failed so i figured
> > heirloom is not that good quality, eg.:
> > nl -b a -v 0
> > (i would never use nl but it turns out the build
> > script mess of dash does ..for whatever reason)
> heirloom toolchest has about four "personalities":
> 1. SVRx (default?)
> 2. BSD
> 3. Single UNIX 3
> 4. SUS
> (The latter two are variants of POSIX)
> In general, the POSIX variants are about as close to precisely
> standards-conformant as you can get; unfortunately, the plain old UNIX
> versions are default. I note, though, that nl presumably ought to start
> numbering at 0 when specified; instead, it starts at 1 (SU3/SUS
> variants), skipping the line that would be numbered 0.  The old unix
> version apparently didn't recognize -b.
> But I figure it beats Busybox any day--and I'd rather not use GNU
> bloat.

I'm not sure what you're talking about. Busybox does not contain GNU
code and hardly has any bloat aside from the source-level bloat
resulting from making it so configurable and micro-optimized for size.

> I'd rather use mksh/ksh93, but if you want a POSIX shell, the Bourne
> shell beats dash on standards-conformance (after all, it *is* the
> standard). mksh (when invoked as sh) is almost pure POSIX.

I'm not sure what conformance issues you claim busybox's ash has, but
I suspect the developers would be happy to hear your bug reports. My
understanding is that except in a few specific areas, the bb utils are
intended to conform to SUSv4.

Rich

Re: compatability: heirloom-utils +.5, libarchive -1

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-01-06 03:41:10 -0500]:

> On Wed, Jan 04, 2012 at 06:05:26PM -0800, Isaac Dunham wrote:
> > On Tue, 3 Jan 2012 18:38:08 +0100
> > In general, the POSIX variants are about as close to precisely
> > standards-conformant as you can get; unfortunately, the plain old UNIX
> > versions are default. I note, though, that nl presumably ought to start
> > numbering at 0 when specified; instead, it starts at 1 (SU3/SUS
> > variants), skipping the line that would be numbered 0.  The old unix
> > version apparently didn't recognize -b.
> > But I figure it beats Busybox any day--and I'd rather not use GNU
> > bloat.
> 
> I'm not sure what you're talking about. Busybox does not contain GNU

imho he meant that heirloom beats busybox in posix conformance
and functionality and much less bloated than gnu

Re: compatability: heirloom-utils +.5, libarchive -1

[Isaac Dunham]

All right, I didn't make stuff clear enough the first time:

Rich Felker <dalias@aerifal.cx> wrote:
> > But I figure it beats Busybox any day--and I'd rather not use GNU
> > bloat.
> I'm not sure what you're talking about. Busybox does not contain GNU
> code and hardly has any bloat aside from the source-level bloat

I'd rather avoid both of the two extremes: Busybox minimalism to
the point of lost functionality--for example, cpio only implements -H
newc, where there are around 4 possible formats; and GNU, with so much
bloat that it supports remote files.
In other words, I want something that beats Busybox (which heirloom
does), and I don't want to get that by using GNU bloat.

> > I'd rather use mksh/ksh93, but if you want a POSIX shell, the Bourne
> > shell beats dash on standards-conformance (after all, it *is* the
> > standard). mksh (when invoked as sh) is almost pure POSIX.

> I'm not sure what conformance issues you claim busybox's ash has,

I'm not saying ash has conformance issues: I'm responding to the remark
about dash (which is intended to be pretty much pure POSIX, though it
does have a few minor differences) not building with heirloom, on the
assumption that some (POSIX-conformant) alternative to ash is desired.
FWIW: dash and ash have the same base: NetBSD's Almquist shell.

> My understanding is that except in a few specific areas, the bb utils
> are intended to conform to SUSv4.
Last I knew, they stated that they considered the standards a
guideline, and explicitly stated that POSIX and GNU options would be
implemented if they were needed for scripts, while rarely-used options
would not be implemented.
The shells (ash & hush) aim for POSIX conformance + some bash
compatability, though.