emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#36518: closed ([core-updates] python-boot0 fails t


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#36518: closed ([core-updates] python-boot0 fails to build on armhf and aarch64)
Date: Sun, 07 Jul 2019 14:43:03 +0000

Your message dated Sun, 07 Jul 2019 16:42:35 +0200
with message-id <address@hidden>
and subject line Re: bug#36518: [core-updates] python-boot0 fails to build on 
armhf and aarch64
has caused the debbugs.gnu.org bug report #36518,
regarding [core-updates] python-boot0 fails to build on armhf and aarch64
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
36518: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36518
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [core-updates] python-boot0 fails to build on armhf and aarch64 Date: Sat, 06 Jul 2019 01:44:50 +0200 User-agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu)
On the core-updates branch, since commit
5f3f70391809f8791c55c05bd1646bc58508fa2c, bootstrapping fails early for
armhf-linux and aarch64 when trying to build pkg-config (for
python-boot0).  That can be easily worked around with this patch:

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index d28296449d..183536d0b4 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -1866,6 +1866,7 @@ the bootstrap environment."
                   (inherit python-minimal)
                   (inputs
                    `(("expat" ,expat-sans-tests))) ;remove OpenSSL, zlib, etc.
+                  (native-inputs '())              ;and pkg-config
                   (arguments
                    (substitute-keyword-arguments (package-arguments
                                                   python-minimal)
But then Python fails at the configure stage because pthreads is not
working with the bootstrap compiler on those platforms.

I'm not sure what to do about it.  I tried using 'python-on-guile' with
this patch:

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index f26145cb0b..747ec7c594 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -816,6 +816,33 @@ with the Linux kernel.")
    (license lgpl2.0+)
    (home-page "https://www.gnu.org/software/libc/";)))
 
+(define-public glibc-sans-python
+  (package
+    (inherit glibc)
+    (name "glibc-with-guile-python")
+    (arguments
+     (substitute-keyword-arguments (package-arguments glibc)
+       ((#:phases phases)
+        `(modify-phases ,phases
+           (add-after 'unpack 'patch-configure
+             (lambda _
+               ;; Relax Python version check.
+               (substitute* "configure"
+                 (("\\$critic_missing python") "")
+                 (("\\$PYTHON_PROG -B") "$PYTHON_PROG"))
+               #t))))))
+    (native-inputs `(("texinfo" ,texinfo)
+                     ("perl" ,perl)
+                     ("bison" ,bison)
+                     ("gettext" ,gettext-minimal)
+                     ("python" ,(@ (gnu packages guile-xyz) python-on-guile))
+                     ,@(if (hurd-target?)
+                           `(("mig" ,mig)
+                             ("perl" ,perl))
+                           '())))))
+
+
+
 ;; Below are old libc versions, which we use mostly to build locale data in
 ;; the old format (which the new libc cannot cope with.)
 
But the interpreter fails with 'unbound variable: this' upon running
glibcs Python scripts.

Until python-on-guile is complete enough to run the glibc scripts, I
think we'll have to insert an older version of glibc into the
bootstrap graph, so that Python can be built with pthreads on all
platforms.  WDYT?

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- Subject: Re: bug#36518: [core-updates] python-boot0 fails to build on armhf and aarch64 Date: Sun, 07 Jul 2019 16:42:35 +0200 User-agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu)
Ricardo Wurmus <address@hidden> writes:

> Hi Marius,
>
>> But the interpreter fails with 'unbound variable: this' upon running
>> glibcs Python scripts.
>
> This means it fell through to the case where “python” is called with
> more than one argument:
>
> --8<---------------cut here---------------start------------->8---
> (define* (main #:optional (args (command-line)))
>   (match args
>     ((_ file)
>      (let ((compiled (string-append file ".go")))
>        (compile-file file
>                      #:from python
>                      #:output-file compiled)
>        (load-compiled compiled)))
>     ((_)
>      (repl-default-option-set! 'prompt ">>> ")
>      (set! (@@ (system repl common) repl-welcome)
>            (const (display "\
> Python on Guile, version 0.1.0
> (Hit Ctrl-D to exit.)
> ")))
>      (start-repl python)
>      #t)
>     (_ (format (current-error-port)
>                "usage: ~a file.py~%" this))))
> --8<---------------cut here---------------end--------------->8---
>
> “this” was supposed to be the first match, i.e. the “python” executable
> itself.  Anyway, the problem is that “python” doesn’t handle any flags
> at all.  I’ll implement option “handling” soon (maybe we can ignore most
> options to “python”).

I pushed a workaround in 4f5fe46388eb70055b6935df053f74b7ccdaf55f, which
uses an older version of Python that can be built without threads.

Attachment: signature.asc
Description: PGP signature


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]