DragonFly kernel List (threaded) for 2004-06
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Crossbuilding DFly on old FBSD
[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)
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]