Project

General

Profile

Bug #374

DragonFly ISO release build failure for 2CSNAP-20061107-2330-Devel

Added by corecode over 14 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Is that fixed?

cheers
simon

History

#1

Updated by dillon over 14 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
#2

Updated by qhwt+dfly over 14 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?

#3

Updated by dillon over 14 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
<>
#4

Updated by TGEN over 14 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

#5

Updated by dillon over 14 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
:

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

Also available in: Atom PDF