Crossbuilding DFly on old FBSD

[Barry Bouwsma]

[As a non-subscriber, I'm not sure if this will get through via
 mail.  Also, my address above is IPv6 only; removing only the
 hostname part makes it work everywhere, but then only when I'm
 online which is unfortunately rare these days.  So, keep any
 replies on the list and I'll try to catch up later from the
 archives/newsfroup.  thanks]


Well hello there.

I note that in the DFly building instructions, it's said that one
can use an up-to-date FreeBSD4 system to crossbuild DragonFlyBSD.

Is there any interest in getting this to work with, say, a not-so-
up-to-date FreeBSD4, or perhaps something entirely different?

What I have is a userland from several years ago on my FreeBSD4
machine, on which I cross-build DFly.  Needed to work around a
few difficulties along the way, but eventually I completed the
buildworld.  (Need to do it again with the benefit of knowledge
gained, to verify it wasn't a fluke after all.)

Would anyone be interested to know where I needed to hack the
source in order for my compilation to succeed, in order to
incorporate proper fixes into DragonFly?

The problems include `patch' now taking an option unsupported
by my old native `patch'; different includes files over the
years; an out-of-date `makeinfo' (probably at a time when no
doc needs to be built anyway).  Still-older systems might have
additional problems.



I'm sure you're aware that NetBSD now has a build infrastructure
that permits a successful crossbuild on pretty much anything.
Rather impressive.  I'd like to see the same for all BSDen,
as over time they diverge from their common ancestry and cross-
building becomes difficult...




thamnks
barry bouwsma

Addendum:  I've taken a look at the NetBSD build process to see
if I could steal any of those ideas, and come up with something
slightly better than my original gross hacks.  Basically,
:-)  I've added another target to the top-level makefile, which
     builds a basic includes directory, and then given that
     priority in the search path, to get up-to-date headers;
:-)  I've frobbed one of the crossbuild targets to do the above
     before building bootstrap tools -- it seems this would
     avoid the need to `make includes' that occasionally is
     given as advice when people have problems, if done routinely;
:-)  I've disabled building of the documentation in the tools
     stages;
:-)  I changed the `patch' reference to something that can be
     overridden, and invoked it as the `patch' built in the
     bootstrap-tools process.  Perhaps it would be preferable
     for me to frob the PATH during the build to give preference
     to just-built tools, which should automagically use the
     newer `patch', but I didn't.  That solution may well fix
     other problems I didn't have too, as might using the
     above include directory everywhere.

I'd be happy to divulge my hacks to do the above, unless the
ideas are All Wrong, though someone with reasonable makefile
competence can undoubtedly convert the above ideas into proper
code, rather than risk nausea by seeing my crude hacks.

(oh yeah, the build from scratch completed, woo hoo)