unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: java-swt: Use other archive on 64-bit systems.
Date: Mon, 09 May 2016 22:03:38 +0200	[thread overview]
Message-ID: <87mvnzq9r9.fsf@elephly.net> (raw)
In-Reply-To: <20160509180342.GA16597@debian-netbook>


Efraim Flashner <efraim@flashner.co.il> writes:

>> -                "03mhzraikcs4fsz7d3h5af9pw1bbcfd6dglsvbk2ciwimy9zj30q"))))
>> +    (source
>> +     ;; The types of many variables and procedures differ in the sources
>> +     ;; dependent on whether the target architecture is a 32-bit system or a
>> +     ;; 64-bit system.  Instead of patching the sources on demand in a build
>> +     ;; phase we download either the 32-bit archive (which mostly uses "int"
>> +     ;; types) or the 64-bit archive (which mostly uses "long" types).
>> +     (let ((hash32 "03mhzraikcs4fsz7d3h5af9pw1bbcfd6dglsvbk2ciwimy9zj30q")
>> +           (hash64 "1qq0pjll6030v4ml0hifcaaik7sx3fl7ghybfdw95vsvxafwp2ff")
>> +           (file32 "x86")
>> +           (file64 "x86_64"))
>> +       (let-values (((hash file)
>> +                     (match (or (%current-target-system) (%current-system))
>> +                       ("i686-linux"     (values hash32 file32))
>> +                       ("x86_64-linux"   (values hash64 file64))
>> +                       ("armhf-linux"    (values hash32 file32))
>> +                       ("mips64el-linux" (values hash64 file64))
>> +                       (_                (values hash32 file32)))))
>
> If the catch-all is for 32-bit then you could leave out i686 and armhf.
> With the values being x86 or x86_64, will it build on arm or mips?

I only have a catch-all here, because I wouldn’t know what else I could
do here.  Practically speaking we only have Icedtea packages for i686
and x86_64 right now, so we could just handle those cases.

The only difference between the different source archives is that the
32-bit version uses “int /*long*/”, whereas the other uses “/*int*/
long” in type declarations.  This is important in at least one place
where the size of the “int” type is used at runtime to check whether we
are on a 32-bit or 64-bit system.

It’s all a bit messy and since we have no way of testing this on
architectures other than i686 and x86_64 I cannot say what a good
default would be.  Maybe it would be better to only handle the two cases
we are sure of, and add others later.  What do you think?

~~ Ricardo

  reply	other threads:[~2016-05-09 20:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 14:16 [PATCH] gnu: java-swt: Use other archive on 64-bit systems Ricardo Wurmus
2016-05-09 18:03 ` Efraim Flashner
2016-05-09 20:03   ` Ricardo Wurmus [this message]
2016-06-07 10:43   ` Ricardo Wurmus
2016-06-07 11:44     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvnzq9r9.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=efraim@flashner.co.il \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).