[erlang-bugs] Erlang/OTP R11B-3 OpenBSD patches

[Mikael Pettersson]

Jon Olsson writes:
 > On Sun, Feb 04, 2007 at 11:03:34PM +0100, Jon Olsson wrote:
 > > Ok, I'll cook something up later this week perhaps.
 > 
 > Here's an updated patch, I'm also including the diff for the amd64
 > floating point exceptions issue.
 > 
 >  erts/configure.in         |    5 +++--
 >  erts/emulator/Makefile.in |    5 +++++
 >  2 files changed, 8 insertions(+), 2 deletions(-)
 > 
 > $OpenBSD: patch-erts_configure_in,v 1.1 2007/02/03 11:48:39 steven Exp $
 > --- erts/configure.in.orig	Mon Jan 29 13:53:26 2007
 > +++ erts/configure.in	Sun Feb 11 22:42:06 2007
 > @@ -304,6 +304,7 @@ SunOS)	case `uname -r` in
 >  Linux)	OPSYS=linux;;
 >  Darwin)	OPSYS=darwin;;
 >  FreeBSD) OPSYS=freebsd;;
 > +OpenBSD) OPSYS=openbsd;;
 >  esac
 >  ARCH=noarch
 >  case `uname -m` in
...
 > --- erts/emulator/Makefile.in.orig	Mon Jan 29 13:52:09 2007
 > +++ erts/emulator/Makefile.in	Sun Feb 11 22:38:23 2007
 > @@ -137,7 +137,12 @@ darwinCFLAGS=-DDARWIN
 >  noopsysCFLAGS=
 >  OPSYSCFLAGS=$($(OPSYS)CFLAGS)
 >  ARCH=@ARCH@
 > +
 > +ifeq ($(OPSYS),openbsd)
 > +ultrasparcCFLAGS=
 > +else
 >  ultrasparcCFLAGS=-Wa,-xarch=v8plusa
 > +endif
 >  ARCHCFLAGS=$($(ARCH)CFLAGS)

While this may solve your immediate problem (64-bit mode code
on OpenBSD/SPARC64), it's inappropriate for other cases: What
if the user prefers to generate 32-bit code on OpenBSD? What
about other operating systems on SPARC64?

I've checked in the patch below which solves the problem by
using ARCH=sparc64 instead of ARCH=ultrasparc when the C compiler
generates 64-bit mode code. This is similar to the solution I
used for x86 machines where `uname` alone is insufficient to
detect if the system will be built in 32- or 64-bit mode.

This patch was required to let me build a 64-bit system on
an Ultra running Linux.

/Mikael

--- otp-0202/erts/configure.in.~1~	2006-11-24 13:51:40.000000000 +0100
+++ otp-0202/erts/configure.in	2007-02-14 19:55:02.000000000 +0100
@@ -308,7 +308,7 @@ esac
 ARCH=noarch
 case `uname -m` in
 sun4u)	ARCH=ultrasparc;;
-sparc64)	ARCH=ultrasparc;;
+sparc64)	ARCH=sparc64;;
 sun4v)	ARCH=ultrasparc;;
 i86pc)	ARCH=x86;;
 i386)	ARCH=x86;;
@@ -327,6 +327,7 @@ esac
 
 dnl
 dnl Convert between x86 and amd64 based on the compiler's mode.
+dnl Ditto between ultrasparc and sparc64.
 dnl
 AC_MSG_CHECKING(whether compilation mode forces ARCH adjustment)
 case "$ARCH-$ac_cv_sizeof_void_p" in
@@ -338,6 +339,14 @@ amd64-4)
 	AC_MSG_RESULT(yes: adjusting ARCH=amd64 to ARCH=x86)
 	ARCH=x86
 	;;
+ultrasparc-8)
+	AC_MSG_RESULT(yes: adjusting ARCH=ultrasparc to ARCH=sparc64)
+	ARCH=amd64
+	;;
+sparc64-4)
+	AC_MSG_RESULT(yes: adjusting ARCH=sparc64 to ARCH=ultrasparc)
+	ARCH=x86
+	;;
 *)
 	AC_MSG_RESULT(no)
 	;;
--- otp-0202/erts/configure.~1~	2006-11-24 13:51:40.000000000 +0100
+++ otp-0202/erts/configure	2007-02-14 19:58:28.000000000 +0100
@@ -1423,7 +1423,7 @@ esac
 ARCH=noarch
 case `uname -m` in
 sun4u)	ARCH=ultrasparc;;
-sparc64)	ARCH=ultrasparc;;
+sparc64)	ARCH=sparc64;;
 sun4v)	ARCH=ultrasparc;;
 i86pc)	ARCH=x86;;
 i386)	ARCH=x86;;
@@ -1451,6 +1451,14 @@ amd64-4)
 	echo "$ac_t""yes: adjusting ARCH=amd64 to ARCH=x86" 1>&6
 	ARCH=x86
 	;;
+ultrasparc-8)
+	echo "$ac_t""yes: adjusting ARCH=ultrasparc to ARCH=sparc64" 1>&6
+	ARCH=amd64
+	;;
+sparc64-4)
+	echo "$ac_t""yes: adjusting ARCH=sparc64 to ARCH=ultrasparc" 1>&6
+	ARCH=x86
+	;;
 *)
 	echo "$ac_t""no" 1>&6
 	;;