From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: mips64el: guild problem Date: Tue, 19 Feb 2013 13:47:06 +0100 Message-ID: <201302191347.06520.andreas@enge.fr> References: <201302181932.28497.andreas@enge.fr> <878v6l45pk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary-01=_KR3IRI2symmunIt" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7mbT-0002Oi-Ft for bug-guix@gnu.org; Tue, 19 Feb 2013 07:47:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7mbJ-0002i0-CL for bug-guix@gnu.org; Tue, 19 Feb 2013 07:47:23 -0500 In-Reply-To: <878v6l45pk.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ludovic =?utf-8?q?Court=C3=A8s?= Cc: bug-guix@gnu.org --Boundary-01=_KR3IRI2symmunIt Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Montag, 18. Februar 2013 schrieb Ludovic Court=C3=A8s: > This =E2=80=9CGOOF=E2=80=9D cookie indicates the Guile Object Object(!) F= ormat. Here, > it says little endian with 8-byte pointers. That corresponds to this > GNU triplet: > However, my guess is that Guile was compiled with the N32 ABI, so it > expects 4-byte words. But Guile=E2=80=99s system/base/target.scm makes t= his > wrong assumption that =E2=80=9Cmips64=E2=80=9D means 8-byte pointers: That sounds like the good diagnostic. Should guile not explicitly test the= =20 size of the types, using the C sizeof or equivalent? From the triplet, one= =20 cannot deduce the ABI. > For now, you can work around it by removing the --target argument from > Makefile.am. >=20 > Can you confirm? Compiling worked so far. Now there is the hash mismatch in=20 http://alpha.gnu.org/gnu/guix/bootstrap/mips64el- linux/20130105/guile-2.0.7.tar.xz . Nikita, could you push your=20 modification with the correct hash, or should I make the suitable=20 modifications on my side? Andreas --Boundary-01=_KR3IRI2symmunIt Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Am Montag, = 18. Februar 2013 schrieb Ludovic Court=C3=A8s:

> This = =E2=80=9CGOOF=E2=80=9D cookie indicates the Guile Object Object(!) Format. = Here,

> it say= s little endian with 8-byte pointers. That corresponds to this

> GNU tr= iplet:

> Howeve= r, my guess is that Guile was compiled with the N32 ABI, so it

> expect= s 4-byte words. But Guile=E2=80=99s system/base/target.scm makes this

> wrong = assumption that =E2=80=9Cmips64=E2=80=9D means 8-byte pointers:

&nb= sp;

That sounds= like the good diagnostic. Should guile not explicitly test the size of the= types, using the C sizeof or equivalent? From the triplet, one cannot dedu= ce the ABI.

&nb= sp;

> For no= w, you can work around it by removing the --target argument from

> Makefi= le.am.

>

> Can yo= u confirm?

&nb= sp;

Compiling w= orked so far. Now there is the hash mismatch in http://alpha.gnu.org/gnu/gu= ix/bootstrap/mips64el-linux/20130105/guile-2.0.7.tar.xz . Nikita, could you= push your modification with the correct hash, or should I make the suitabl= e modifications on my side?

&nb= sp;

Andreas

&nb= sp;

--Boundary-01=_KR3IRI2symmunIt--