Re: 32-bit Python interpreter on a 64-bit system (ARM)
On 2023-12-12 15:09:52 +, 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.
signature.asc
Description: PGP signature
Re: 32-bit Python interpreter on a 64-bit system (ARM)
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 # …)
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 # …)
In srfi/srfi-1.scm:
586:17 4 (map1 (("_" #< bindings: ((#<) …))
In guix/profiles.scm:
383:46 3 (package->manifest-entry #< 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: #<
bindings: ((#< 7f3322b456a0 proc: #> #)) thunk: #>
From: Csepp
Sent: Sunday, December 10, 2023 9:03 AM
To: Wicki Gabriel (wicg)
Cc: help-guix@gnu.org
Subject: Re: 32-bit Python interpreter on a 64-bit system (ARM)
“Wicki Gabriel (wicg)” 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)” 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.
32-bit Python interpreter on a 64-bit system (ARM)
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!
