Project

General

Profile

Actions

Bug #374

closed

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

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

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

0%

Estimated time:

Description

Is that fixed?

cheers
simon

Actions #1

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

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

Actions #3

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

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

Actions #5

Updated by dillon over 17 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
Actions

Also available in: Atom PDF