GNU bug report logs - #19749
orpheus does not build on mips64

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19749 in the body.
You can then email your comments to 19749 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: bug-guix <at> gnu.org
Subject: orpheus does not build on mips64
Date: Mon, 2 Feb 2015 23:28:19 +0100

Hello,

the orpheus package fails to build on mips64 with the following message:

checking build system type... ./config.guess: unable to guess system type
This script, last modified 2001-07-12, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
 ftp://ftp.gnu.org/pub/gnu/config/

Orpheus itself seems to be unmaintained (the last release dates from 2006).
I would suggest to either drop the package, or to disable it on mips.

Andreas

Message #8 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andreas Enge <andreas <at> enge.fr>
Cc: 19749 <at> debbugs.gnu.org
Subject: Re: bug#19749: orpheus does not build on mips64
Date: Tue, 03 Feb 2015 01:04:38 -0500

Andreas Enge <andreas <at> enge.fr> writes:

> the orpheus package fails to build on mips64 with the following message:
>
> checking build system type... ./config.guess: unable to guess system type
> This script, last modified 2001-07-12, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
>  ftp://ftp.gnu.org/pub/gnu/config/
>
> Orpheus itself seems to be unmaintained (the last release dates from 2006).

The config.guess problem can be easily worked around by passing
--build=<triplet> to configure.  I would suggest something similar to
what I did in the gmp package to get it working on armhf:

   (arguments `(#:configure-flags
                '(;; Build a "fat binary", with routines for several
                  ;; sub-architectures.
                  "--enable-fat"
                  "--enable-cxx"

                  ;; FIXME: gmp-6.0.0a's config.guess fails on
                  ;; multi-core armhf systems.
                  ,@(if (%current-target-system)
                        '()
                        (let ((triplet
                               (nix-system->gnu-triplet (%current-system))))
                          (list (string-append "--build=" triplet)))))))

Would you like to try this?

> I would suggest to either drop the package, or to disable it on mips.

Please, let's not disable builds on MIPS unless it is clear that it
would be a very difficult job to get it working.

       Mark

Message #11 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 19749 <at> debbugs.gnu.org
Subject: Re: bug#19749: orpheus does not build on mips64
Date: Wed, 4 Feb 2015 17:20:21 +0100

On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote:
> The config.guess problem can be easily worked around by passing
> --build=<triplet> to configure.  I would suggest something similar to
> what I did in the gmp package to get it working on armhf:
>    (arguments `(#:configure-flags
>                 '(;; Build a "fat binary", with routines for several
>                   ;; sub-architectures.
>                   "--enable-fat"
>                   "--enable-cxx"
> 
>                   ;; FIXME: gmp-6.0.0a's config.guess fails on
>                   ;; multi-core armhf systems.
>                   ,@(if (%current-target-system)
>                         '()
>                         (let ((triplet
>                                (nix-system->gnu-triplet (%current-system))))
>                           (list (string-append "--build=" triplet)))))))
> Would you like to try this?

Alternatively, could we not simply copy a newer config.guess as a patch
into the source tree? If yes, what would be preferable?

Andreas

Message #14 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andreas Enge <andreas <at> enge.fr>
Cc: 19749 <at> debbugs.gnu.org
Subject: Re: bug#19749: orpheus does not build on mips64
Date: Thu, 05 Feb 2015 11:08:11 -0500

Andreas Enge <andreas <at> enge.fr> writes:

> On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote:
>> The config.guess problem can be easily worked around by passing
>> --build=<triplet> to configure.  I would suggest something similar to
>> what I did in the gmp package to get it working on armhf:
>>    (arguments `(#:configure-flags
>>                 '(;; Build a "fat binary", with routines for several
>>                   ;; sub-architectures.
>>                   "--enable-fat"
>>                   "--enable-cxx"
>> 
>>                   ;; FIXME: gmp-6.0.0a's config.guess fails on
>>                   ;; multi-core armhf systems.
>>                   ,@(if (%current-target-system)
>>                         '()
>>                         (let ((triplet
>>                                (nix-system->gnu-triplet (%current-system))))
>>                           (list (string-append "--build=" triplet)))))))
>> Would you like to try this?
>
> Alternatively, could we not simply copy a newer config.guess as a patch
> into the source tree? If yes, what would be preferable?

The patch would be quite large.  I think it's cleaner to pass --build.

In fact, I think we should pass --build to _all_ builds by default,
because on several architectures config.guess looks at /proc/cpuinfo and
the output of uname to optimize for the particular CPU in the build
machine, which I think we don't want.  However, Ludovic resisted and I
haven't yet had time to follow up on that.

    Thanks,
      Mark

Message #17 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 19749 <at> debbugs.gnu.org
Date: Mon, 9 Feb 2015 13:10:24 -0300

Sorry for reopening this, Fabián. You're right in pointing that this
bug was introduced by my fix to 19665. But AFAICS 19665 is indeed a
bug: you want to go to the end of the defun line when the search is
backward, in order to match arg defun including the current one.

There is a more difficult problem here. Say * is the point:

1) You want C-M-a to move the point from def* to *def.

2) You want C-M-a to mode the point from *def to the previous definition.

(1) is addressed by 19665.
(2) is addressed by this report.

Still, there is:

3) You want C-M-h both in def* and in *def to select the current
defun. 19665 was intended to correct both cases (*def and def*), but
my patch here breaks again the case *def (because for *def the
selection reverts now to the pathological behavior described in 19665,
just because of the additional condition in the guard, which should be
kept anyway because of (2)).

Note: I'm checking my assertions 1, 2 and 3 against the standard
behavior of elisp mode, which I take as a reference. That's indeed the
behavior there.

More briefly: for C-M-a you want to distinguish between def* and *def,
but for C-M-h you don't. The previous fix here and 19665 correctly
address (1) and (2), and mostly address (3) except for the corner case
*class, which I address in what follows.

Looking at the definition of mark-defun one could clearly see what the
problem is. Starting from *class, say, mark-defun will mark the
previous defun and then check (if (> (point) opoint) to see that the
selected defun was not the desired one. So it goes through the else
part sending the point to the end of the class block and then moving
backward one defun to select just the last method. I think we could
fix this tweaking a bit the behavior of mark-defun, but -unusually-
mark-defun allows for no local extension points. A simple advice could
do the trick but I don't feel like adding an advice just for python
sake to a globally and often used function. The last option I'm able
figure out is to replace mark-defun in the python keymap. This is not
perfect, as mark-defun could be used programatically also, but I
believe it's good enough:

(define-key map [remap mark-defun] 'python-mark-defun)

(defun python-mark-defun ()
  (interactive)
  (when (python-info-looking-at-beginning-of-defun)
    (end-of-line 1))
  (mark-defun))

Besides that, I want to emphazise that you still need:

-            (when (and (< arg 0)
+            (when (and (> arg 0)

and

+                       (> (current-column) (current-indentation))

Cheers
--
Carlos

Message #20 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 19749 <at> debbugs.gnu.org
Cc: Fabián Ezequiel Gallina <fgallina <at> gnu.org>
Subject: Re:
Date: Mon, 9 Feb 2015 13:36:32 -0300

Also, you could want to set allow-extend for mark-defun.

I will post a patch to 19665 including the original change and the
mark-defun fix.

The  (> (current-column) (current-indentation)) fix in this report
remains valid except you worked out a cleaner solution for 1, 2 and 3
above.


On Mon, Feb 9, 2015 at 1:10 PM, Carlos Pita <carlosjosepita <at> gmail.com> wrote:
> Sorry for reopening this, Fabián. You're right in pointing that this
> bug was introduced by my fix to 19665. But AFAICS 19665 is indeed a
> bug: you want to go to the end of the defun line when the search is
> backward, in order to match arg defun including the current one.
>
> There is a more difficult problem here. Say * is the point:
>
> 1) You want C-M-a to move the point from def* to *def.
>
> 2) You want C-M-a to mode the point from *def to the previous definition.
>
> (1) is addressed by 19665.
> (2) is addressed by this report.
>
> Still, there is:
>
> 3) You want C-M-h both in def* and in *def to select the current
> defun. 19665 was intended to correct both cases (*def and def*), but
> my patch here breaks again the case *def (because for *def the
> selection reverts now to the pathological behavior described in 19665,
> just because of the additional condition in the guard, which should be
> kept anyway because of (2)).
>
> Note: I'm checking my assertions 1, 2 and 3 against the standard
> behavior of elisp mode, which I take as a reference. That's indeed the
> behavior there.
>
> More briefly: for C-M-a you want to distinguish between def* and *def,
> but for C-M-h you don't. The previous fix here and 19665 correctly
> address (1) and (2), and mostly address (3) except for the corner case
> *class, which I address in what follows.
>
> Looking at the definition of mark-defun one could clearly see what the
> problem is. Starting from *class, say, mark-defun will mark the
> previous defun and then check (if (> (point) opoint) to see that the
> selected defun was not the desired one. So it goes through the else
> part sending the point to the end of the class block and then moving
> backward one defun to select just the last method. I think we could
> fix this tweaking a bit the behavior of mark-defun, but -unusually-
> mark-defun allows for no local extension points. A simple advice could
> do the trick but I don't feel like adding an advice just for python
> sake to a globally and often used function. The last option I'm able
> figure out is to replace mark-defun in the python keymap. This is not
> perfect, as mark-defun could be used programatically also, but I
> believe it's good enough:
>
> (define-key map [remap mark-defun] 'python-mark-defun)
>
> (defun python-mark-defun ()
>   (interactive)
>   (when (python-info-looking-at-beginning-of-defun)
>     (end-of-line 1))
>   (mark-defun))
>
> Besides that, I want to emphazise that you still need:
>
> -            (when (and (< arg 0)
> +            (when (and (> arg 0)
>
> and
>
> +                       (> (current-column) (current-indentation))
>
> Cheers
> --
> Carlos

Message #23 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 19749 <at> debbugs.gnu.org
Subject: Re:
Date: Mon, 9 Feb 2015 13:50:30 -0300

Sorry for the typo, the last two comments were intended to be for
19748. I don't know if it's possible to delete them from debbugs
control interface. Shame on me.

Message #26 received at 19749 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: 19749 <at> debbugs.gnu.org
Cc: Mark H Weaver <mhw <at> netris.org>
Subject: Progress
Date: Tue, 19 Feb 2019 23:53:41 +0100

Hello,

this bug dates from a time where it was still almost realistic to reach
zero non-building packages... Should we close it, since mips has been
removed from the release architectures?

Andreas

Message #31 received at 19749-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Andreas Enge <andreas <at> enge.fr>
Cc: 19749-done <at> debbugs.gnu.org
Subject: Re: bug#19749: Progress
Date: Wed, 20 Feb 2019 00:52:53 -0500

[Message part 1 (text/plain, inline)]

On Tue, Feb 19, 2019 at 11:53:41PM +0100, Andreas Enge wrote:
> Hello,
> 
> this bug dates from a time where it was still almost realistic to reach
> zero non-building packages... Should we close it, since mips has been
> removed from the release architectures?

Yes, I've closed it.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.