Update: crossbuilding under older 4.x FreeBSD

[Barry Bouwsma]

[don't reply to me yet -- keep replies on the list for now]

> :So, um, my real question would be, is it reasonable for me to
> :want to create a DFly-specific `includes' directory at the start
> :of my crossbuild so that I can get the latest headers to work

>     No.

Ah, thanks for correcting the error of my ways.


>   I think what we need to do is to make sure that the build tools
>     portion of the buildworld can be built using legacy include files. 
>     Putting #ifdef __DragonFly__ checks around the appropriate places, if
>     we don't have to do too many, would be the solution.

You mean, that I should mangle the source files...

Well, I've decided to take that approach to see if I'm
on the right track yet.  The biggest difference between
my older 4.x FreeBSD system and a newer one or DFly, is
that I don't have langinfo goodies yet.

This affects the following source files in the bootstrap-
tools section of the build:
src/bin/ls/print.c
src/usr.bin/find/ls.c

As far as I can see, the only call for this is to order the
date format for the user's locale (we over here like to see
things like 02.09.2004 and 02 Sep 2004, while others prefer
Sep 02 2004).  I can't imagine that this is too critical in
a bootstrap-tool, but I don't know how it gets used.

So what I've done is to hack the ls/find Makefiles to test
if BOOTSTRAPPING is defined, as it is for the 'strap-tool
stage, and if so, add an unconditional -DNOLANGINFO to the
CFLAGS, rather than do a test for __FreeBSD_version < whatever.
I'm taking the easy way out, which I hope still works.

Then inside the above source files, I wrap the #include <langinfo>
with a NOLANGINFO ifdef, and use the same to decide whether to
use *nl_langinfo() later, or hardcode the date-first variable.



These are the only locations which have given me problems now
with source from early 30.Aug, avoiding use of my previous
ugly hacks.  So far -- the build is still plodding along.

Here's a sample of my hack for `find' for comments; `ls' is
similar but messier:

--- source-hacks/usr.bin/find/Makefile-ORIG	Tue Jun 17 06:29:26 2003
+++ source-hacks/usr.bin/find/Makefile	Thu Sep  2 12:53:26 2004
@@ -3,6 +3,12 @@
 # $DragonFly: src/usr.bin/find/Makefile,v 1.2 2003/06/17 04:29:26 dillon Exp $
 
 CFLAGS+=-Wall
+
+# HACK XXX
+.if defined(BOOTSTRAPPING)
+CFLAGS+= -DNOLANGINFO
+.endif
+
 PROG=	find
 SRCS=	find.c function.c ls.c main.c misc.c operator.c option.c getdate.y
 YFLAGS=




--- source-hacks/usr.bin/find/ls.c-ORIG	Sat Oct  4 22:36:44 2003
+++ source-hacks/usr.bin/find/ls.c	Thu Sep  2 12:51:50 2004
@@ -40,7 +40,12 @@
 
 #include <err.h>
 #include <errno.h>
+
+/* XXX HACK */
+#ifndef NOLANGINFO
 #include <langinfo.h>
+#endif /* NOLANGINFO */
+
 #include <stdio.h>
 #include <string.h>
 #include <time.h>
@@ -86,10 +91,17 @@
 	char longstring[80];
 	static time_t now;
 	const char *format;
+
+/* XXXX UGly HACK */
+#ifdef NOLANGINFO
+	static int d_first = 0;
+#else
 	static int d_first = -1;
 
 	if (d_first < 0)
 		d_first = (*nl_langinfo(D_MD_ORDER) == 'd');
+#endif /* NOLANGINFO */
+
 	if (now == 0)
 		now = time(NULL);
 


Perhaps there's a way to build the nl_langinfo-containing
component as part of the bootstrap-tools and get it to be
used by `ls' and `find' there, avoiding the above entirely,
but I don't know how.  Alternatively, the __DFly__ and/or
__FBSD_version checks could be substituted, although I'm
not yet clear at what stages of a crossbuild process are
those variables set.  For the latter, I have the following
from a different patch:
+#if __FreeBSD_version >= 450002 /* nl_langinfo introduced */

Is it true that for my FreeBSD-hosted crossbuild, the bootstrap-
tools will see __FreeBSD_version as 450000 and no __DFLY__,
and as soon as the actual `world' target is built, that the
__FreeBSD_version is no longer defined as 450000 (if anything,
480101), while __DFly__ will be set to something?  I ask because
I'm unsure what happens when.  If this is true, then one can
dispense with my BOOTSTRAP hack altogether and use _version
appropriately -- assuming my hardcoding of d_first doesn't
introduce any problems or inconsistencies...


thanks
barry bouwsma