Efraim Flashner <[email protected]> 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
