Re: Crossbuilding DFly on old FBSD

[Barry Bouwsma <freebsd-misuser@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On 08.Jun, nearly two months ago by now, Justin C. Sherril replied to me:

> Barry Bouwsma wrote:
> > I'd be happy to divulge my hacks to do the above, unless the

> Post it in the dragonfly.submit newsgroup/submit@ mailing list.  Given that
> we're probably less than a month from release 1 at this point, I don't know
> how much of a chance anyone will have to look at it, though.  If you can
> wait until July, life should be quieter.

Okay, not waiting by choice, but finally here we go.  I've downloaded
the source from ten days ago, and built it to verify this message is
still relevant.  Sorry for the delay in this, as I've been offline
too much.  As usual, drop me from any replies and I'll catch the
archives when I have the chance.
 ----------------------------------------------------------------

Hello.

This is a belated followup to my message of well over a month
ago where I mentioned I'm crossbuilding DFlyBSD on an older
FreeBSD 4.x system, and experience problems I've patched
around in the DFly source.



There are a few places where the `patch' binary is taken from
the default path.  This could be overridden in the build
environment; as an alternative I decided to change this to a
user-definable `$PATCH' which, when appropriate, I define to
be that of the build process rather than of the host system.

This works around the problem where the `patch' on my old
FreeBSD4 system does not understand the `-i' option.


--- /stand/DragonFly-src/source-hacks/gnu/usr.bin/binutils214/ld/Makefile-ORIG	Sun Mar 28 18:26:33 2004
+++ /stand/DragonFly-src/source-hacks/gnu/usr.bin/binutils214/ld/Makefile	Sun Jun  6 00:13:41 2004
@@ -14,12 +16,14 @@
 CONTRIBDIR=	${SRCDIR}/ld
 CLEANFILES+=	emultempl/elf32.em genscripts.sh
 
+PATCH?=	patch
+
 emultempl/elf32.em: ${CONTRIBDIR}/emultempl/elf32.em patches/elf32.em.patch
 	mkdir -p emultempl
-	patch -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
+	${PATCH} -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
 
 genscripts.sh: ${CONTRIBDIR}/genscripts.sh patches/genscripts.sh.patch
-	patch -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
+	${PATCH} -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
 
 depend: emultempl/elf32.em genscripts.sh
 


--- /stand/DragonFly-src/source-hacks/share/mk/bsd.dep.mk-ORIG	Fri Mar  5 02:06:50 2004
+++ /stand/DragonFly-src/source-hacks/share/mk/bsd.dep.mk	Sun Jun  6 03:08:14 2004
@@ -70,9 +70,11 @@
 .for _PSRC in ${SRCS:M*.patch}
 .for _PC in ${_PSRC:T:S/.patch$//:S|,|/|g}
 
+PATCH?=	patch
+
 ${_PC}: ${CONTRIBDIR}/${_PC} ${_PSRC}
 	mkdir -p ${.TARGET:H}
-	patch -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
+	${PATCH} -o ${.TARGET} -i ${.ALLSRC:M*.patch} ${CONTRIBDIR}/${.TARGET}
 
 SRCS:=	${SRCS:N${_PC}:S|${_PSRC}|${_PC}|}
 CLEANFILES:=	${CLEANFILES} ${_PC}



The bulk of my ugly hacks are done in the top-level makefile,
as revealed below.  Note that at the end there's a `schnellworld'
target that I added for my convenience, to allow me to remove
all the already-completed steps of the build process to speed
things up on my ten-or-so-year-old build machine.  Ignore this.

The rest of it should be pretty clear.  Note that the _crossincludes
target I added (the ugliest part of this hack) is used at the end,
where `schnellworld' can be found.

My original message may have a few details about these hacks.

As a reminder, I have problems with a few includes files, and
some binaries on my system aren't compatible with what is
expected for the crossbuild.  Therefore I populate my own
includes tree to get up-to-date headers, and change a few of
the things that get built earlier on.



--- /stand/DragonFly-src/source-hacks/Makefile.inc1-ORIG	Wed May 26 21:28:57 2004
+++ /stand/DragonFly-src/source-hacks/Makefile.inc1	Sun Jun  6 09:42:16 2004
@@ -180,6 +180,11 @@
 TMPDIR?=	/tmp
 TMPPID!=	echo $$$$
 
+ID?=	/usr/bin/id
+.if !defined(UID)
+UID!=	${ID} -u
+.endif
+
 #
 # Building a world goes through the following stages
 #
@@ -208,7 +213,12 @@
 		DESTDIR=${BTOOLSDEST} \
 		INSTALL="sh ${.CURDIR}/tools/install.sh"
 
+## Use the system headers as much as possible building the tools...
+##		  COPTS="-isystem ${BTOOLSDEST}/usr/include" \
+# (The bsd.dep.mk file uses some bad juju that doesn't grok the above yet)
+
 BMAKE=		${BMAKEENV} ${MAKE} -f Makefile.inc1 -DBOOTSTRAPPING \
+		COPTS="-I${BTOOLSDEST}/usr/include" \
 		-DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED \
 		-DNO_WERROR
 
@@ -220,6 +230,7 @@
 		INSTALL="sh ${.CURDIR}/tools/install.sh"
 
 TMAKE=		${TMAKEENV} ${MAKE} -f Makefile.inc1 -DBOOTSTRAPPING \
+		-DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED \
 		-DNO_FORTRAN
 
 # cross-tool stage
@@ -233,10 +244,18 @@
 		OBJTREE=${OBJTREE} \
 		DESTDIR=${CTOOLSDEST} \
 		INSTALL="sh ${.CURDIR}/tools/install.sh" \
+		PATCH=${BTOOLSDEST}/usr/bin/patch \
 		TOOLS_PREFIX=${CTOOLSDEST} \
 		USRDATA_PREFIX=${WORLDDEST}
+##    We need to use our bootstrap version of patch on older systems.
+## One could probably do this without mangling the Makefile/mk files
+## by setting the PATH appropriately, btools given priority, instead.
+##    While we're at it, there seems to be a few things that build
+## doc, sometimes wanting outdated `makeinfo', so let's skip that, ok?
+#   (does -nopic/profile/shared make a difference here?)
 
 XMAKE=		${XMAKEENV} ${MAKE} -f Makefile.inc1 -DNO_FORTRAN -DNO_GDB \
+		-DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED \
 		-DBOOTSTRAPPING
 
 # world stage, note the strict path and note that TOOLS_PREFIX is left
@@ -301,6 +320,27 @@
 		-p ${WORLDDEST}/usr/include > /dev/null
 	ln -sf ${.CURDIR}/sys ${WORLDDEST}
 
+## Add a target to be used to build a skeleton includes tree, to be
+## given preference when crossbuilding, in case the host system is
+## lacking some headers.  (The full includes tree is built below,
+## but does this require the tools to be built already???)
+_crossincludes:
+	@echo
+	@echo "--------------------------------------------------------------"
+	@echo ">>> stage -1: populating a skeleton includes tree"
+	@echo ">>>  in ${BTOOLSDEST}/usr/include"
+	@echo "--------------------------------------------------------------"
+.if ${UID} != 0
+	@echo
+	@echo "  Errors seen in building as non-root during this part"
+	@echo "  of the build related to setting owner or group mode"
+	@echo "  can be ignored."
+	@echo
+	@sleep 4
+	@echo
+.endif
+	cd ${.CURDIR}/include; ${BMAKEENV} ${MAKE}  installincludes 
+	touch ${BTOOLSDEST}/.includes_done
 _bootstrap-tools:
 	@echo
 	@echo "--------------------------------------------------------------"
@@ -382,7 +422,11 @@
 
 realquickworld: _obj _includes _libraries everything
 
-crossworld: _worldtmp _bootstrap-tools _obj _build-tools _cross-tools
+## Add a target to skip steps already completed successfully...
+schnellworld: _includes  _libraries _depend everything
+
+## Hack this target to add a stage populating includes for crossbuilds...
+crossworld: _worldtmp   _crossincludes   _bootstrap-tools _obj _build-tools _cross-tools
 
 .ORDER: ${WMAKE_TGTS}
 


As always, review this carefully before thinking about applying to
any source tree.  Remember, I know less than you do, and I have no
idea what I'm doing.

thanks
barry bouwsma



P.S.:  After the release, I've downloaded the latest code (mid-July)
and again crossvuilding on my outdated system.  The import of gcc34
has generated another Makefile where `patch' needs to be overridden
in my case.

Also, this definition needs to be supplied earlier in the top-level
makefile, like so:

OOPS.  I didn't copy my latest hacks from my other machine with the
source I built, now far away from me.  However, above I hack the
top-level Makefile to add PATCH=... to one step of the build, while
the latest gcc34 is built in the step right above (cross-tools?)

The makefile in the gcc34 source, whose pathname I forget, needs a
patch just like the one above too -- it can probably be found by
searching `patch' within all the makefiles under gcc34.  Sorry I
don't have my hacked source here to be more precise.


Again, this may well also be the wrong way to go about getting the
newly-built `patch' to be used; I think other OSen fudge the PATH
in order to prefer the newly-built binaries, so as I say, someone
with knowledge should incorporate the correct fix.


thanks again,
barry bouwsma