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
next prev parent 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).