1.22.0 builds still broken due to strchrnul mis-declaration on FreeBSD

[Matthias Andree]

Am 08.01.2014 15:26, schrieb Denys Vlasenko:
> On Wed, Jan 8, 2014 at 12:34 AM, Matthias Andree <mandree at freebsd.org> wrote:
>> Am 07.01.2014 14:09, schrieb Denys Vlasenko:
>>> On Tue, Jan 7, 2014 at 1:43 AM, Matthias Andree <mandree at freebsd.org> wrote:
>>>> FreeBSD/HEAD fails to build busybox 1.22.0, because busybox's
>>>> strchrnul() declaration is in conflict with FreeBSD's; sources at
>>>> <http://svnweb.freebsd.org/base/head/include/string.h?annotate=246803#l75>.
>>>>
>>>> There is, unfortunately, no exact version tag that you can test against,
>>>> but on FreeBSD, you might use:
>>>>
>>>> // sys/param.h is system-specific
>>>> #include <sys/param.h>
>>>> #if __FreeBSD_version < 1000029
>>>> // declare strchrnul
>>>> #endif
>>>>
>>>> Please fix busybox to not declare strchrnul if the system provides it.
>>>
>>> Does attached patch work for you?
>>>
>>
>> It's not complete.  I am attaching my complete series of patches from
>> the FreeBSD port.  Please consider them for inclusion.
> 
> archival/unzip.c, coreutils/cp.c, coreutils/dirname.c, coreutils/install.c,
> coreutils/rmdir.c patches all ad just one line:
> 
> +#include <libgen.h>
> 
> This looks bogus: libgen.h is already included by libbb.h.
> Why do you need these patches? Does build really
> not work without them?

Then this was changed between my last check and 1.22.0, and in fact it
works without these particular patches.

>> I also run these in-place-editing sed commands routinely before the
>> build to replace obsolescent headers by modern equivalents:
>>
>> /usr/bin/sed -i.bak -e 's/<malloc.h>/<stdlib.h>/'  \
>>         busybox-1.22.0/libbb/appletlib.c  busybox-1.22.0/shell/hush.c
>>
>> /usr/bin/sed -i.bak -e 's/<alloca.h>/<stdlib.h>/'  \
>>         busybox-1.22.0/scripts/basic/*.c
>>
>> Please consider modifying the sources accordingly.
> 
> stdlib.h is included by libbb.h too.
> As comment in hush.h says, it needs malloc.h to be able to call
> malloc_trim(), not merely malloc().

That is glibc-specific, so it is unlikely you would have malloc_trim()
anywhere but on some Linux boxes (those using glibc), and I think you
may want to put #include <malloc.h> like this (you can't use features.h,
it's system specific; but feature test macros and resulting #defines are
provided through #include <unistd.h>):

#include <unistd.h>
#ifdef __GLIBC__
# include <malloc.h>
#endif


FreeBSD does not use glibc, and does not have malloc_trim().
This is FreeBSD's malloc.h, without comment banner:

#if __STDC__
#error "<malloc.h> has been replaced by <stdlib.h>"
#else
#include <stdlib.h>
#endif

So for any reasonable level of standards enforcement you need to forego
#include <malloc.h> unless you are sure you can use it.

Feel free to not apply the patch, and use the suggestion above instead.

>> widening types sufficiently for the baudrate
>> tables - FreeBSD defines all baudrate constants to the actual baudrate,
>> so they do not fit into a short, starting with 38400 and stepping upwards.
> 
> A struct with "short" and "int" fields has padding, effectively
> making it take as much space as two ints.

Yes.  So either you truncate data and remove all records that you cannot
represent, or you extend and possibly pad the other value.  And I am not
so sure that this is limited to FreeBSD.

NetBSD has the same issue, see lines 215ff. in
<http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/termios.h?annotate=1.32&only_with_tag=MAIN>,
and a working hypothesis is so do OpenBSD and DragonflyBSD.

> I'm adding #if defined __FreeBSD__ there so that others don't suffer,
> care to code a better fix?

You should be using #include <termios.h> and actually also speed_t as
the type (which isn't saving you a bit because it's an unsigned int).

> Please try current git.

Better, but still does not work due to use of alloca.h in
scripts/basic/fixdep.c l. 116 and scripts/basic/docproc.c l. 42.

Perhaps C99 variable-sized vectors might be an alternative these days?
(FreeBSD has alloca() in <stdlib.h>.)

Or you might want to wrap #include <alloca.h> under #ifdef __GLIBC__, as
shown above (requires #include <unistd.h> before).


BTW I forgot to mention that the sed scripts running underneath GEN are
also GNU-sed specific, so I need to use GNU sed, rather than BSD's sed,
to build things, and I need to patch the executable name because there
is no SED variable I could set to gsed.

"gmake hosttools" also fails, rather than building a sed, as advertised.
(It is advertised by 'gmake help'.)

gmake is GNU make.

$ LC_ALL=C gmake hosttools
gmake: *** No rule to make target `hosttools'.  Stop.

Hope that helps,
Matthias