pkgsrc-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[pkgsrc/trunk]: pkgsrc/bootstrap Revise ABI discussion
details: https://anonhg.NetBSD.org/pkgsrc/rev/d042e6885609
branches: trunk
changeset: 349764:d042e6885609
user: gdt <gdt%pkgsrc.org@localhost>
date: Fri Jul 15 14:51:16 2016 +0000
description:
Revise ABI discussion
Substantially revise the ABI 32/64 discussion, separating the
close-in-time changes about the default ABI vs how it is encoded.
Thanks to jperkin for off-list clarifications.
diffstat:
bootstrap/README.MacOSX | 71 +++++++++++++++++++++++++++++++++---------------
1 files changed, 48 insertions(+), 23 deletions(-)
diffs (98 lines):
diff -r 06aa9bbfe862 -r d042e6885609 bootstrap/README.MacOSX
--- a/bootstrap/README.MacOSX Fri Jul 15 13:44:59 2016 +0000
+++ b/bootstrap/README.MacOSX Fri Jul 15 14:51:16 2016 +0000
@@ -1,4 +1,4 @@
-$NetBSD: README.MacOSX,v 1.30 2016/07/14 23:35:05 gdt Exp $
+$NetBSD: README.MacOSX,v 1.31 2016/07/15 14:51:16 gdt Exp $
This file describes the use of current versions of pkgsrc with
multiple versions of Darwin and OS X, omitting information about previous pkgsrc
@@ -46,41 +46,66 @@
** i386 vs x86_64 ABI issue
+This entire section is only about Intel Macs.
+
OS X 10.6 and higher supports x86-64 binaries on Intel Macs with
-x86-64 processors, which is now most of them.
+x86-64 processors, which is now most of them. i386 binaries are also
+supported on most (all?) Intel machines.
+
+*** issues related to ABI 32 vs 64
-This has caused problems with packages which get confused because
-"MACHINE_ARCH" is in some OS versions set to "i386" (on a 64-bit
-system!).
+Note that a pkgsrc package built in x86_64 mode will not run on an
+Intel Mac that is i386 only. For a longer discussion, see:
+http://mail-index.NetBSD.org/pkgsrc-users/2009/09/24/msg010817.html
+
+Somewhat separately from pkgsrc's ABI choice, there have been issues
+with packages which get confused because "MACHINE_ARCH" is in some OS
+versions set to "i386" (on a 64-bit system!). As of 2016 this should
+be mostly resolved.
version: uname -m : uname -p
10.6: i386 : i386
10.9: x86_64 : i386
-On Intel machines, pkgsrc currently defaults to i386 mode (--abi=32)
-on OS X, and can be set to x86_64 mode (--abi=64).
-Note that a pkgsrc build in x86_64 mode will not run on an Intel Mac
-that is i386 only. For a longer discussion, see:
- http://mail-index.NetBSD.org/pkgsrc-users/2009/09/24/msg010817.html
+*** default ABI
-As of 2015-11-09, the default ABI is x86_64 on machines where "uname
+The ABI is chosen at bootstrap time and encoded into mk.conf. So a
+change in the default is about what a new bootstrap will do;
+already-bootstrapped systems should remain unchanged. They should be
+able to build and run new packages using the old ABI value.
+
+pkgsrc used to set the default ABI as i386, both on systems with i386
+processors and on systems with x86_64 processors. On 2015-11-09 the
+default was changed so that ABI=64 is chosen on machines where "uname
-m" reports x86_64. (It remains i386 on others, which are not capable
of running x86_64 binaries.)
-*** resolving issues from a change in default ABI
+Generally, users will not need to deal with the default ABI change,
+except that packages are mostly only portable across machines with the
+same bootstrapping parameters.
-When the ABI changes from 32 to 64, you can recover without a
-rebootstrap by replacing bmake and pkg_install. See
+If one unpacks a new binary bootstrap kit over an existing
+installation, one can end up with a mix. The standard advice is not to
+do this, and to rrebuild/reinstall all packages from scratch or a
+compatible binary package set. But, one could also mark packages with
+the wrong ABI as rebuild=YES and use pkg_rolling-replace.
+
+*** change in storage of ABI information
+
+On 2016-01-24, the way ABI information was stored in pkgsrc was
+rationalized and simplified. The new code could compute the wrong ABI
+for some previously-bootstrapped installations. The problem can be
+resolved by building bmake with MACHINE_ARCH=x86_64 and updating that
+package, as described in mail archives:
+
https://mail-index.netbsd.org/pkgsrc-users/2016/01/25/msg022870.html
-In /usr/pkgsrc/devel/bmake, do:
-# bmake MACHINE_ARCH=x86_64 replace
-and then rerun the failed pkg_add -U with an additional -f.
-Then, in /usr/pkgsrc/pkgtools/pkg_install, do:
-# bmake replace
-
-Then, rebuild all packages; ABI=32 and ABI=64 packages both work
-individually, but mixing them in a single program via dynamic linking
-will not work.
+(One would expect to be able to use make replace to do this. One
+minor issue is that it requires pkg_tarup, although that will be
+present on systems of those who use make replace. There also may be
+an error with architecture mismatch from pkg_install requiring a "-f"
+option. Repeatable data about recovery is somewhat hard to obtain, as
+most are past this issue already and no longer interested in
+experimenting.)
** sed in 10.9
Home |
Main Index |
Thread Index |
Old Index