Re: Crossbuilding DFly on old FBSD

看板DFBSD_submit作者時間21年前 (2004/07/30 11:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串1/8 (看更多)
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
文章代碼(AID): #112S5000 (DFBSD_submit)
討論串 (同標題文章)
文章代碼(AID): #112S5000 (DFBSD_submit)