Bug #374
closedDragonFly ISO release build failure for 2CSNAP-20061107-2330-Devel
Added by corecode about 18 years ago. Updated about 18 years ago.
0%
Description
Is that fixed?
cheers
simon
Updated by dillon about 18 years ago
:> mkdep -f .depend -a =20
:...
:> /usr/obj/usr/src/world_i386/usr/include/time.h:48:29: =20
:> machine/uvparam.h: No such file or directory
:> mkdep: compile failed
:> *** Error code 1
:
:Is that fixed?
:
:cheers
: simon
I'll do a buildworld and nrelease run and fix whatever problems crop
up.
Is your snap build doing a buildworld followed by a buildkernel? Or
is just doing a 'nativekernel' build? You may have to manually update
the 'make' and 'config' programs, or build and install a new world.
-Matt
Updated by qhwt+dfly about 18 years ago
But it's buildworld that is failing. The `make' program inherits ${MACHINE}
from either the environment variable with the same name, or from
`sysctl -n hw.machine'. So if you try to run buildworld of HEAD on a
pre-infrastructure-change kernel (either 1.6.x-RELEASE or 1.7.x-DEVELOPMENT),
you'll get this error because header files in /sys/machine/pc32/include
won't get installed into ${WORLDDEST}, because ${MACHINE} expands to i386,
not pc32 as expected. Doing something like
env MACHINE=pc32 make buildworld
got me past this stage, but wouldn't we like to avoid having to do this
in the next release?
Updated by dillon about 18 years ago
:But it's buildworld that is failing. The `make' program inherits ${MACHINE}
:from either the environment variable with the same name, or from
:`sysctl -n hw.machine'. So if you try to run buildworld of HEAD on a
:pre-infrastructure-change kernel (either 1.6.x-RELEASE or 1.7.x-DEVELOPMENT),
:you'll get this error because header files in /sys/machine/pc32/include
:won't get installed into ${WORLDDEST}, because ${MACHINE} expands to i386,
:not pc32 as expected. Doing something like
:
: env MACHINE=pc32 make buildworld
:
:got me past this stage, but wouldn't we like to avoid having to do this
:in the next release?
I think the solution here is to simply detect the situation and have
the buildworld abort with a message telling the user what they have
to do. I'll do it right now.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by TGEN about 18 years ago
Wouldn't it be better to warn the user, sleep for a couple of seconds,
then set it to pc32, then continue the build?
Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net
Updated by dillon about 18 years ago
:Wouldn't it be better to warn the user, sleep for a couple of seconds,
:then set it to pc32, then continue the build?
:
:Cheers,
:--
: Thomas E. Spanjaard
: tgen@netphreax.net
No. It's a one-time deal. All that needs to be done is to not leave
the user scratching his head wondering what to do. We don't want to
try to outsmart him... we want the build to stop cold so the problem
can be corrected.
-Matt