Erlang 10.b.9 compile bug on Debian GNU/Linux SPARC [was: Fwd: Bug#328031: Fwd: erlang 10.b.9]

[Mikael Pettersson]

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 <jurij@REDACTED>
>To: 328031@REDACTED
>
>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