Am 08.01.2014 15:26, schrieb Denys Vlasenko: > On Wed, Jan 8, 2014 at 12:34 AM, Matthias Andree <[email protected]> wrote: >> Am 07.01.2014 14:09, schrieb Denys Vlasenko: >>> On Tue, Jan 7, 2014 at 1:43 AM, Matthias Andree <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
