32-bit Python interpreter on a 64-bit system (ARM)

32-bit Python interpreter on a 64-bit system (ARM)

[Wicki Gabriel (wicg)]

Hello!

Due to dynamic linkage to a library that is only provided for ARMv6 architecture (32-bit) my Python application that is developed for a 64-bit ARM architecture refuses to work (I load the library with ctypes).  According to the internet this could be solved by running that script with a 32-bit interpreter which - of course - is readily available in Guix.
How can I declare on the package (or on the system level if necessary) that this specific script needs the interpreter of a different architecture than the system/package is built for?

To give you an example, the end-product will be a whole system configuration with packages and services and whatnot, that will be generated throught guix system image my-img.scm --system=aarch64-linux​ but this one package must make use of the armhf-linux Python ELF.

Thanks for any ideas and input!

Re: 32-bit Python interpreter on a 64-bit system (ARM)

[Csepp]

“Wicki Gabriel (wicg)” <wicg@zhaw.ch> writes:

> Hello!
>
> Due to dynamic linkage to a library that is only provided for ARMv6 architecture
> (32-bit) my Python application that is developed for a 64-bit ARM architecture
> refuses to work (I load the library with ctypes). According to the internet this
> could be solved by running that script with a 32-bit interpreter which - of
> course - is readily available in Guix.
> How can I declare on the package (or on the system level if necessary) that this
> specific script needs the interpreter of a different architecture than the
> system/package is built for?
>
> To give you an example, the end-product will be a whole system configuration
> with packages and services and whatnot, that will be generated throught guix
> system image my-img.scm –system=aarch64-linux​ but this one package must make
> use of the armhf-linux Python ELF.
>
> Thanks for any ideas and input!

Maybe a cursed idea and completely untested, but you could wrap the expression
that evaluates to the Python package with a block that temporarily changes the
current-system or target-system parameters.  I think there is already a Guile
function for this, most likely named with-parameters.

Re: 32-bit Python interpreter on a 64-bit system (ARM)

[Wicki Gabriel (wicg)]

Hi

Thanks for the input, Csepp, this seems to be exactly what I was looking for!

Now I include the altered package like so:
`

(package
  (name foo)
  ...
  (propagated-inputs
   (list
    (with-parameters ((%current-system "armhf-linux"))
      some-package)))
  ...
  )

`

But this produces the following error message when building package "foo".  What am I missing?  I am able to ,lower and ,build the (with-parameters) package in a repl so i guess the expression itself is fine?


Backtrace:
          18 (primitive-load "/home/gabriel/.cache/guix/inferiors/dr…")
In guix/ui.scm:
   2323:7 17 (run-guix . _)
  2286:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37 13 (thunk)
   1298:8 12 (call-with-build-handler #<procedure 7f3322b32450 at g…> …)
In guix/status.scm:
    839:4 11 (call-with-status-report _ _)
In guix/scripts/environment.scm:
    340:4 10 (_)
In srfi/srfi-1.scm:
   673:15  9 (append-map _ _ . _)
   586:29  8 (map1 _)
   586:17  7 (map1 ((package ad-hoc-package "nMASC-bin") (# . #t) # …))
In guix/scripts/environment.scm:
    323:4  6 (_ _)
In guix/profiles.scm:
   386:19  5 (package->manifest-entry #<package nMASC-bin@0.1 guix/…> …)
In srfi/srfi-1.scm:
   586:17  4 (map1 (("_" #<<parameterized> bindings: ((#<<param…>) …))
In guix/profiles.scm:
   383:46  3 (package->manifest-entry #<<parameterized> bindings: (…> …)
   377:19  2 (default-properties _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure package-properties: Wrong type argument: #<<parameterized> bindings: ((#<<parameter> 7f3322b456a0 proc: #<procedure 7f3322b46600 at ice-9/boot-9.scm:1315:5 () | (x)>> #<procedure 7f330adf3fa0 at ice-9/eval.scm:330:13 ()>)) thunk: #<procedure 7f330adf3f80 at ice-9/eval.scm:330:13 ()>>



________________________________
From: Csepp <raingloom@riseup.net>
Sent: Sunday, December 10, 2023 9:03 AM
To: Wicki Gabriel (wicg) <wicg@zhaw.ch>
Cc: help-guix@gnu.org <help-guix@gnu.org>
Subject: Re: 32-bit Python interpreter on a 64-bit system (ARM)

“Wicki Gabriel (wicg)” <wicg@zhaw.ch> writes:

> Hello!
>
> Due to dynamic linkage to a library that is only provided for ARMv6 architecture
> (32-bit) my Python application that is developed for a 64-bit ARM architecture
> refuses to work (I load the library with ctypes). According to the internet this
> could be solved by running that script with a 32-bit interpreter which - of
> course - is readily available in Guix.
> How can I declare on the package (or on the system level if necessary) that this
> specific script needs the interpreter of a different architecture than the
> system/package is built for?
>
> To give you an example, the end-product will be a whole system configuration
> with packages and services and whatnot, that will be generated throught guix
> system image my-img.scm –system=aarch64-linux​ but this one package must make
> use of the armhf-linux Python ELF.
>
> Thanks for any ideas and input!

Maybe a cursed idea and completely untested, but you could wrap the expression
that evaluates to the Python package with a block that temporarily changes the
current-system or target-system parameters.  I think there is already a Guile
function for this, most likely named with-parameters.

Re: 32-bit Python interpreter on a 64-bit system (ARM)

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]

On 2023-12-12 15:09:52 +0000, Wicki Gabriel (wicg) wrote:
> Hi
>
> Thanks for the input, Csepp, this seems to be exactly what I was looking for!
>
> Now I include the altered package like so:
> `
>
> (package
>   (name foo)
>   ...
>   (propagated-inputs
>    (list
>     (with-parameters ((%current-system "armhf-linux"))
>       some-package)))
>   ...
>   )
>
> `
>
> But this produces the following error message when building package "foo".  What am I missing?  I am able to ,lower and ,build the (with-parameters) package in a repl so i guess the expression itself is fine?

I cannot say what you are doing wrong, but my interest got piqued so I gave it a
try as well.  It works for me:

$ guix build --no-offload -f /tmp/test.scm
[..]
/gnu/store/867m8dkv9hzsl4c1nqrj1nzg502a4l3c-hello-2.10

$ file /gnu/store/867m8dkv9hzsl4c1nqrj1nzg502a4l3c-hello-2.10/bin/python-native/bin/python3.10
/gnu/store/867m8dkv9hzsl4c1nqrj1nzg502a4l3c-hello-2.10/bin/python-native/bin/python3.10: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped
$ file /gnu/store/867m8dkv9hzsl4c1nqrj1nzg502a4l3c-hello-2.10/bin/python-i686/bin/python3.10
/gnu/store/867m8dkv9hzsl4c1nqrj1nzg502a4l3c-hello-2.10/bin/python-i686/bin/python3.10: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped

So for me it seems to work.  My package definition (adjusted hello package from
the cookbook), maybe you can use it as a starting point:

(use-modules (gnu)
             (gnu packages)
             (gnu packages python)
             (guix build-system gnu)
             (guix download)
             (guix gexp)
             (guix licenses)
             (guix packages))

(package
  (name "hello")
  (version "2.10")
  (source (origin
            (method url-fetch)
            (uri (string-append "mirror://gnu/hello/hello-" version
                                ".tar.gz"))
            (sha256
             (base32
              "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
  (inputs `(("python-native" ,python)
            ("python-i686"   ,(with-parameters ((%current-system "i686-linux"))
                                python))))
  (build-system gnu-build-system)
  (arguments
   (list
    #:phases
    #~(modify-phases %standard-phases
        (add-after 'install 'link-pythons
          (lambda* (#:key inputs #:allow-other-keys)
            (symlink (assoc-ref inputs "python-native")
                     (string-append #$output "/bin/python-native"))
            (symlink (assoc-ref inputs "python-i686")
                     (string-append #$output "/bin/python-i686")))))))
  (synopsis "Hello, GNU world: An example GNU package")
  (description
   "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
  (home-page "https://www.gnu.org/software/hello/")
  (license gpl3+))


Hope this helps,
Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]