make[1]: Entering directory /var/tmp/portage/sci-mathematics/maxima-5.43.2/work/maxima-5.43.2/src echo (load ../lisp-utils/defsystem.lisp) (mk:add-registry-location ../src/) (load ../lisp-utils/make-depends.lisp) (funcall (intern CREATE-DEPENDENCY-FILE :mk) binary-ccl64/maxima.image ccl64-depends.mk.tmp) (ccl:quit) | ccl /bin/sh: ccl: command not found echo (load ../lisp-utils/defsystem.lisp) (mk:add-registry-location ../src/) (load ../lisp-utils/make-depends.lisp) (funcall (intern CREATE-DEPENDENCY-FILE :mk) binary-sbcl/maxima.core sbcl-depends.mk.tmp) (sb-ext:quit) | sbcl --noinform --noprint STYLE-WARNING: using deprecated EVAL-WHEN situation names EVAL LOAD COMPILE STYLE-WARNING: using deprecated EVAL-WHEN situation names EVAL LOAD COMPILE ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1-libressl-20200325-090553 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.3.0 * clang version 10.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.7 [3] python3.6 [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.42.0 [2] rust-1.42.0 * Available Java Virtual Machines: (none found) The Glorious Glasgow Haskell Compilation System, version 8.0.2 timestamp of HEAD at this tinderbox image: /var/db/repos/gentoo Sun 29 Mar 2020 02:38:54 AM UTC /var/db/repos/libressl Thu 19 Mar 2020 04:37:24 PM UTC emerge -qpvO sci-mathematics/maxima [ebuild N ] sci-mathematics/maxima-5.43.2 USE="nls unicode -X -clisp -clozurecl (-cmucl) -ecls -emacs -gcl -sbcl -test -tk" L10N="-de -es -pt -pt-BR"
Created attachment 626872 [details] emerge-info.txt
Created attachment 626874 [details] emerge-history.txt
Created attachment 626876 [details] environment
Created attachment 626878 [details] etc.portage.tbz2
Created attachment 626880 [details] logs.tbz2
Created attachment 626882 [details] sci-mathematics:maxima-5.43.2:20200329-072725.log
Created attachment 626884 [details] temp.tbz2
This is probably cause by the changes to fix bug 665364
(In reply to Erik Zeek from comment #8) > This is probably cause by the changes to fix bug 665364 You are right, --with-ccl64=ccl apparently implies --enable-ccl64.
Created attachment 629160 [details, diff] ebuild patch fixing the problem
Sorry! It looks like I caused this problem, but I wasn't CC'ed on the corresponding bug to see the follow-up comment. I don't think the proposed patch will work, either. On 32-bit systems, we'll wind up passing both --enable-ccl and --with-ccl64=ccl, which tries to enable both the 32- and 64-bit ccl implementations (which maxima treats as different lisps). I imagine the 64-bit one will fail in that case, but I no longer have any 32-bit hardware to test. There are no good options here, since we need to know whether we're building for a 32-bit or 64-bit machine before we can configure maxima. Maybe the least-bad option is to add a new lisp flag to maxima called "ccl64", and to mask USE=ccl on amd64 (etc) and mask USE=ccl64 on x86 (etc)? Truly ideal would be if maxima didn't treat ccl and ccl64 differently, but we have to work within the bounds of reality...
(In reply to Michael Orlitzky from comment #11) > > There are no good options here, since we need to know whether we're building > for a 32-bit or 64-bit machine before we can configure maxima. Maybe the > least-bad option is to add a new lisp flag to maxima called "ccl64", and to > mask USE=ccl on amd64 (etc) and mask USE=ccl64 on x86 (etc)? > This doesn't work so well in the current ebuilds because the names of the lisp implementations are supposed to correspond exactly to packages in dev-lisp. So, in particular, we can't have two different names for clozurecl. I'm going to make a new revision without all of the bash array looping and see how it looks. Most of the loops already have special cases (and fixing this bug adds one more), so I think the result will actually be much cleaner and shorter. For example, we can use IUSE defaults to set the default lisp these days, and mask the defaults that don't work on a particular arch in the profiles. Even where this introduces some copy/paste it isn't necessarily bad. The length of the CONF_FLAG array combined with the loop itself turns out to be longer than just listing a bunch of $(use_enable ...) lines directly. We'll see. I'm going to have to recompile and test maxima about ten times though so it may take a day or two.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33d71eafab35a8f6083ebeeaa849a7c0a5d82e29 commit 33d71eafab35a8f6083ebeeaa849a7c0a5d82e29 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-03-27 11:35:44 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-03-29 12:42:05 +0000 sci-mathematics/maxima: new revision with separate ccl/ccl64 support. In Gentoo, both the 32-bit and 64-bit versions of clozurecl are provided by the same package and executable name (ccl). Maxima however treats them as separate lisp implementations, with two complete sets of configure flags. To make that work correctly in the ebuild, we'd need to have a bunch of special cases for the user's architecture. Instead, this commit adds a separate "clozurecl64" USE flag to complement the existing, now 32-bit, "clozurecl" flag. This will allow us to mask the 32-bit flag in the 64-bit profiles and vice-versa. Closes: https://bugs.gentoo.org/665364 Closes: https://bugs.gentoo.org/715278 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/maxima/maxima-5.44.0-r5.ebuild | 231 +++++++++++++++++++++++++ sci-mathematics/maxima/metadata.xml | 4 +- 2 files changed, 234 insertions(+), 1 deletion(-)
