Hi,
I am forwarding the information from upstream to the bug so that it will
not get lost (see below). I've checked the build procedure and, indeed,
the architecture detection is done by looking at the output of 'uname -m'.
On Solaris this returns "sun4u" on ultrasparc hardware, our kernel returns
'sparc64'. I've made a simple patch against configure.ac (attached), which
fixes the detection. When I apply this patch and the one mentioned
earlier, the package builds fine. So if you have the reason to upload the
10.b.9 soon, please include them, at least it will not die while building
on sparc.
I see two other issues to take care of: the unreliability of the floating
point exceptions which upstream mentioned, and the special flags which are
passed to the assembler while building erlang. The former I'll have to
look into, the latter might prevent the resulting binaries from working on
sparc32 hardware. However, whether the support for such hardware will be
included in etch is uncertain at this point, so this is not of immediate
concern.
Best regards,
Jurij Smakov [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
---------- Forwarded message ----------
Date: Tue, 27 Dec 2005 15:49:34 -0500
From: "[iso-8859-1] François-Denis Gonthier" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], Will Newton <[EMAIL PROTECTED]>
Subject: Fwd: Re: Erlang 10.b.9 compile bug on Debian GNU/Linux SPARC [was: Fwd:
Bug#328031: Fwd: erlang 10.b.9]
--Boundary-01=_ejasDIxuBBXtT+7
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
This is the answer of one member of [EMAIL PROTECTED]
Here I'm puzzled Will. Should we upload anyway? It seems to me that Jurij=
=20
setup might be the cause of the build failure on his system.
Jurij, Mikael there would probably be glad if you contacted him to investig=
ate=20
that build failure. Does the build also fail with the raw upstream source=
=20
from erlang.org site?
=2D--------- Forwarded Message ----------
Subject: Re: Erlang 10.b.9 compile bug on Debian GNU/Linux SPARC [was: Fwd:=
=20
Bug#328031: Fwd: erlang 10.b.9]
Date: 27 December 2005 03:04
=46rom: Mikael Pettersson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
On Mon, 26 Dec 2005 22:35:12 -0500, Denis Gonthier wrote:
Erlang 10.b.9 was ready to be uploaded when this guy came in on an old com=
p=3D
ile=3D20
bug on sparc for version 10.b.7. I suggested that he try the 10.b.9 packa=
g=3D
e=3D20
and he came up with this.
Having no access to sparc machines, so I'm ressorting to you guys.
Can anyone confirm, infirm, or contribute anything to this bug?
Attached is the first patch he contributed.
=3D2D--------- Forwarded Message ----------
Subject: Bug#328031: Fwd: erlang 10.b.9
Date: 22 December 2005 00:59
=3D46rom: Jurij Smakov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
On Tue, 20 Dec 2005, Fran=3DE7ois-Denis Gonthier wrote:
Erlang 10.b.9 is just around the corner, and it's probably not too late =
to
upload it with your patch.
Could you please download the current version of the erlang 10.b.9 packa=
ge
and try to build it on Sparc? It's at http://neutronic.mine.nu/unstable
The source package downloaded from this site fails to build on sparc due
to a different error. It happens while compiling the source file
erts/emulator/beam/erl_bif_info.c:
beam/erl_bif_info.c:1041: error: 'am_ultrasparc' undeclared (first use in
this function) beam/erl_bif_info.c:1041: error: (Each undeclared identifi=
er
is reported only once beam/erl_bif_info.c:1041: error: for each function =
it
appears in.)
You can find a complete build log at http://www.wooyd.org/debian/erlang/
According to the build log, the build was conducted on a machine
claiming (via uname) to be "sparc64", running in 32-bit mode
(sizeof(void*)=3D=3D4), with HiPE enabled by ./configure and not
disabled by erts/configure.
The error (am_ultrasparc undefined) indicates that HiPE didn't quite
recognise the machine as being an ultrasparc.
My guess is that either erts/configure.in isn't properly handling
Debian's uname results on SPARC64-in-32-bit-mode, or that GCC on
Debian SPARC64-in-32-bit-mode isn't defining the same preprocessor
symbols that GCC on Solaris does: see erts/emulator/hipe/hipe_arch.h
for example. We (the HiPE group) can only test SPARC under Solaris,
so someone else needs to do the detailed analysis (or provide us
with an account on the affected machine).
HOWEVER, the build log also indicates that floating-point exceptions
aren't reliable on the machine. This is not surprising since neither
we (HiPE) nor (I think) Ericsson/OTP run SPARCs under Linux, but it
also means that HiPE won't work unless everything is compiled with
"no-inline-fp". FP exceptions do work on SPARCs under Solaris and
{x86,amd64,ppc32} under Linux, so it's probably not difficult to make
this work. Again, we can't do this porting work due to lack of access
to SPARC/Debian boxes.
/Mikael
=2D------------------------------------------------------
--Boundary-01=_ejasDIxuBBXtT+7
Content-Type:
Content-Transfer-Encoding: 7bit
On Mon, 26 Dec 2005 22:35:12 -0500, Denis Gonthier wrote:
Erlang 10.b.9 was ready to be uploaded when this guy came in on an old comp=
ile=20
bug on sparc for version 10.b.7. I suggested that he try the 10.b.9 packag=
e=20
and he came up with this.
Having no access to sparc machines, so I'm ressorting to you guys.
Can anyone confirm, infirm, or contribute anything to this bug?
Attached is the first patch he contributed.
=2D--------- Forwarded Message ----------
Subject: Bug#328031: Fwd: erlang 10.b.9
Date: 22 December 2005 00:59
=46rom: Jurij Smakov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
On Tue, 20 Dec 2005, Fran=E7ois-Denis Gonthier wrote:
Erlang 10.b.9 is just around the corner, and it's probably not too late to
upload it with your patch.
Could you please download the current version of the erlang 10.b.9 package
and try to build it on Sparc? It's at http://neutronic.mine.nu/unstable
The source package downloaded from this site fails to build on sparc due
to a different error. It happens while compiling the source file
erts/emulator/beam/erl_bif_info.c:
beam/erl_bif_info.c:1041: error: 'am_ultrasparc' undeclared (first use in
this function) beam/erl_bif_info.c:1041: error: (Each undeclared identifier
is reported only once beam/erl_bif_info.c:1041: error: for each function it
appears in.)
You can find a complete build log at http://www.wooyd.org/debian/erlang/
According to the build log, the build was conducted on a machine
claiming (via uname) to be "sparc64", running in 32-bit mode
(sizeof(void*)==4), with HiPE enabled by ./configure and not
disabled by erts/configure.
The error (am_ultrasparc undefined) indicates that HiPE didn't quite
recognise the machine as being an ultrasparc.
My guess is that either erts/configure.in isn't properly handling
Debian's uname results on SPARC64-in-32-bit-mode, or that GCC on
Debian SPARC64-in-32-bit-mode isn't defining the same preprocessor
symbols that GCC on Solaris does: see erts/emulator/hipe/hipe_arch.h
for example. We (the HiPE group) can only test SPARC under Solaris,
so someone else needs to do the detailed analysis (or provide us
with an account on the affected machine).
HOWEVER, the build log also indicates that floating-point exceptions
aren't reliable on the machine. This is not surprising since neither
we (HiPE) nor (I think) Ericsson/OTP run SPARCs under Linux, but it
also means that HiPE won't work unless everything is compiled with
"no-inline-fp". FP exceptions do work on SPARCs under Solaris and
{x86,amd64,ppc32} under Linux, so it's probably not difficult to make
this work. Again, we can't do this porting work due to lack of access
to SPARC/Debian boxes.
/Mikael
--Boundary-01=_ejasDIxuBBXtT+7----- a/erts/configure.ac 2005-12-29 13:21:21.000000000 -0800
+++ b/erts/configure.ac 2005-12-29 13:07:06.000000000 -0800
@@ -218,7 +218,7 @@
esac
ARCH=noarch
case `uname -m` in
-sun4u) ARCH=ultrasparc;;
+sun4u|sparc64) ARCH=ultrasparc;;
i86pc) ARCH=x86;;
i386) ARCH=x86;;
i486) ARCH=x86;;
