NetBSD Problem Report #48906
From email@example.com Sat Jun 14 02:21:03 2014
Received: from mail.netbsd.org (mail.netbsd.org [22.214.171.124])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id DA0DBA653D
for <gnats-bugs@gnats.NetBSD.org>; Sat, 14 Jun 2014 02:21:03 +0000 (UTC)
Date: Fri, 13 Jun 2014 21:05:54 -0400 (EDT)
Subject: bootstrap MACHINE_ARCH handling issues
>Synopsis: bootstrap MACHINE_ARCH handling issues
>Arrival-Date: Sat Jun 14 02:25:00 +0000 2014
>Last-Modified: Mon Jun 16 09:05:00 +0000 2014
>Originator: David A. Holland
>Release: pkgsrc 20140613
1. The bootstrap script explicitly probes and sets MACHINE_ARCH for
all platforms except: Cygwin, Interix, OSF1, SCO_SV, and UnixWare.
This represents an odd choice of platforms to fall back to defaults
on. (If anything, these are platforms where the default is likely to
be messed up.) It should set MACHINE_ARCH for all OSes.
2. The bootstrap script does not have an option to set MACHINE_ARCH
explicitly. You can set it via --mk-fragment, but it isn't immediately
obvious if doing it this way propagates to everywhere it needs to
reach, and even if it currently does it might not in the future. There
should be an explicit option, perhaps "--build-for=arch" or something
2a. If you set MACHINE_ARCH in the environment when calling bootstrap,
it will register in some places and not others -- this should be
either explicitly supported or (my preference) ignored in favor of
explicit arguments only.
3. For most of the OSes MACHINE_ARCH is blindly set to uname output
with no crosschecking. There should be (after the big case for OS
types) a big case for MACHINE_ARCH to make sure that wrong stuff,
whether arising from user mistakes or from uname results that don't
match what we expect, fails or at least gets warned about up front.
Only known values and spellings (this includes all the arm variants)
should be accepted without question. Certain known wrong values, like
"mips", should be explicitly rejected. (I don't think it's necessary,
however, to try to maintain a list of known OS and MACHINE_ARCH
pairs. If you bootstrap for e.g. IRIX on PowerPC you deserve the
4. The bootstrap script uses different logic for whether it exports
MACHINE_ARCH in the environment to its subprocesses and whether it
issues a MACHINE_ARCH line into the output mk.conf. This cannot be
5. As I understand things bmake compiles in the value of MACHINE_ARCH;
bootstrap should make sure that the value bootstrap chooses is always
the value compiled in. In this case it should never be necessary to
set MACHINE_ARCH in mk.conf. Alternatively we could always let bmake
compile in the native value that it works out for itself, always set
MACHINE_ARCH in mk.conf, and never use the compiled-in value in
pkgsrc. (Not sure which of these choices is more desirable. I don't
really like having things compiled in, though.)
6. This interacts with cross-compiling, but AIUI for cross-compiling
we set MACHINE_ARCH explicitly to the crosscompile target arch when
bootstrapping and that's that, and the changes described above make it
possible to do so tidily and have it behave predictably.
7. None of this is adequately documented.
From: "OBATA Akio" <firstname.lastname@example.org>
Subject: Re: pkg/48906: bootstrap MACHINE_ARCH handling issues
Date: Mon, 16 Jun 2014 18:02:47 +0900
As recent porting to new platforms, just fixes devel/bmake/files/machine.sh,
no need to handle MACHINE_ARCH in bootstrap/bootstrap and mk/bsd.prefs.mk,
except ABI selection from multi-arch support now.
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.