Package: guix-patches;
Reported by: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
Date: Mon, 2 Dec 2019 08:08:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: help-debbugs <at> gnu.org (GNU bug Tracking System) To: Ludovic Courtès <ludo <at> gnu.org> Cc: tracker <at> debbugs.gnu.org Subject: bug#38454: closed ([PATCH] gnu: lapack: Update to 3.9.0.) Date: Tue, 07 Jan 2020 10:21:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Tue, 07 Jan 2020 11:20:12 +0100 with message-id <871rsblg9v.fsf <at> gnu.org> and subject line Re: [bug#38454] [PATCH] gnu: lapack: Update to 3.9.0. has caused the debbugs.gnu.org bug report #38454, regarding [PATCH] gnu: lapack: Update to 3.9.0. to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs <at> gnu.org.) -- 38454: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38454 GNU Bug Tracking System Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Konrad Hinsen <konrad.hinsen <at> fastmail.net> To: guix-patches <at> gnu.org Subject: [PATCH] gnu: lapack: Update to 3.9.0. Date: Thu, 28 Nov 2019 22:11:55 +0100* gnu/packages/maths.scm (lapack): Update to 3.9.0. --- gnu/packages/maths.scm | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm index 16e070eeff..de45bdfed3 100644 --- a/gnu/packages/maths.scm +++ b/gnu/packages/maths.scm @@ -544,7 +544,7 @@ large scale eigenvalue problems.") (define-public lapack (package (name "lapack") - (version "3.7.1") + (version "3.9.0") (source (origin (method url-fetch) @@ -552,26 +552,18 @@ large scale eigenvalue problems.") version ".tgz")) (sha256 (base32 - "1j51r7n5w4k7r3lrvy7710xrpkg40wf4rqnmngfz6ck9ypckzign")))) + "1155qixp26c12yrxc76z9mlfw2h3xxymxxv5znpgzh5gaykpndgj")))) (build-system cmake-build-system) (home-page "http://www.netlib.org/lapack/") (inputs `(("fortran" ,gfortran) - ("python" ,python-2))) + ("python" ,python-wrapper))) (arguments `(#:configure-flags (list "-DBUILD_SHARED_LIBS:BOOL=YES" "-DLAPACKE=ON" - ;; Build the 'LAPACKE_clatms' functions. - "-DLAPACKE_WITH_TMG=ON") - #:phases - (modify-phases %standard-phases - (add-before 'check 'patch-python - (lambda* (#:key inputs #:allow-other-keys) - (let ((python (assoc-ref inputs "python"))) - (substitute* "lapack_testing.py" - (("/usr/bin/env python") python))) - #t))))) + "-DLAPACKE_WITH_TMG=ON" + "-DBUILD_TESTING=ON"))) (synopsis "Library for numerical linear algebra") (description "LAPACK is a Fortran 90 library for solving the most commonly occurring -- 2.24.0
[Message part 3 (message/rfc822, inline)]
From: Ludovic Courtès <ludo <at> gnu.org> To: Konrad Hinsen <konrad.hinsen <at> fastmail.net> Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, Mathieu Othacehe <m.othacehe <at> gmail.com>, 38454-done <at> debbugs.gnu.org Subject: Re: [bug#38454] [PATCH] gnu: lapack: Update to 3.9.0. Date: Tue, 07 Jan 2020 11:20:12 +0100Hi Konrad, (Mathieu, Danny: see below for qemu-binfmt concerns. :-)) Ludovic Courtès <ludovic.courtes <at> inria.fr> skribis: > Konrad Hinsen <konrad.hinsen <at> fastmail.net> skribis: > >> * gnu/packages/maths.scm (lapack): Update to 3.9.0. > > Unfortunately this fails to build on armhf-linux (tested via > qemu-binfmt): > > starting phase `configure' > source directory: "/tmp/guix-build-lapack-3.9.0.drv-0/lapack-3.9.0" (relative from build: "../lapack-3.9.0") > build directory: "/tmp/guix-build-lapack-3.9.0.drv-0/build" > running 'cmake' with arguments ("../lapack-3.9.0" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/ynakjwrsq06j7q75ysqfrmhp8mhhdxrb-lapack-3.9.0" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/ynakjwrsq06j7q75ysqfrmhp8mhhdxrb-lapack-3.9.0/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DBUILD_SHARED_LIBS:BOOL=YES" "-DLAPACKE=ON" "-DLAPACKE_WITH_TMG=ON" "-DBUILD_TESTING=ON") > -- The Fortran compiler identification is unknown > CMake Error at /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/CMakeCompilerIdDetection.cmake:26 (list): > list sub-command REMOVE_ITEM requires two or more arguments. > Call Stack (most recent call first): > /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/CMakeDetermineCompilerId.cmake:211 (compiler_id_detection) > /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/CMakeDetermineCompilerId.cmake:230 (CMAKE_DETERMINE_COMPILER_ID_WRITE) > /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/CMakeDetermineCompilerId.cmake:32 (CMAKE_DETERMINE_COMPILER_ID_BUILD) > /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/CMakeDetermineCCompiler.cmake:116 (CMAKE_DETERMINE_COMPILER_ID) > CMakeLists.txt:3 (project) > > [… repeated several times…] This turned out to be a side effect of building through qemu-binfmt; building on real hardware succeeds. So, patch committed, at last—sorry for the delay! --8<---------------cut here---------------start------------->8--- starting phase `configure' source directory: "/tmp/guix-build-lapack-3.9.0.drv-0/lapack-3.9.0" (relative from build: "../lapack-3.9.0") build directory: "/tmp/guix-build-lapack-3.9.0.drv-0/build" running 'cmake' with arguments ("../lapack-3.9.0" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/stor e/ynakjwrsq06j7q75ysqfrmhp8mhhdxrb-lapack-3.9.0" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE " "-DCMAKE_INSTALL_RPATH=/gnu/store/ynakjwrsq06j7q75ysqfrmhp8mhhdxrb-lapack-3.9.0/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" "- DBUILD_SHARED_LIBS:BOOL=YES" "-DLAPACKE=ON" "-DLAPACKE_WITH_TMG=ON" "-DBUILD_TESTING=ON") -- The Fortran compiler identification is GNU 7.4.0 -- The C compiler identification is GNU 7.4.0 -- Check for working Fortran compiler: /gnu/store/91iyya22d6s055iwlwja3vvlpc4i8sih-gfortran-7.4.0/bin/gfortran -- Check for working Fortran compiler: /gnu/store/91iyya22d6s055iwlwja3vvlpc4i8sih-gfortran-7.4.0/bin/gfortran -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /gnu/store/91iyya22d6s055iwlwja3vvlpc4i8sih-gfortran-7.4.0/bin/gfortran supports Fortran 90 -- Checking whether /gnu/store/91iyya22d6s055iwlwja3vvlpc4i8sih-gfortran-7.4.0/bin/gfortran supports Fortran 90 -- yes -- Check for working C compiler: /gnu/store/pkx3kcvj1mbkkgzxi1w57c1vfvhwzxh7-gcc-7.4.0/bin/gcc -- Check for working C compiler: /gnu/store/pkx3kcvj1mbkkgzxi1w57c1vfvhwzxh7-gcc-7.4.0/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done --8<---------------cut here---------------end--------------->8--- So, what’s going on under qemu-binfmt? When doing a qemu-binfmt build, ‘CMakeOutput.log’ contains several instances of: --8<---------------cut here---------------start------------->8--- The system is: Linux - 5.4.8-gnu - armv7l Compiling the Fortran compiler identification source file "CMakeFortranCompilerId.F" succeeded. Compiler: /gnu/store/91iyya22d6s055iwlwja3vvlpc4i8sih-gfortran-7.4.0/bin/gfortran Build flags: Id flags: -v --8<---------------cut here---------------end--------------->8--- Yet ‘CMakeError.log’ reads: --8<---------------cut here---------------start------------->8--- Compilation of the Fortran compiler identification source "CMakeFortranCompilerId.F" did not produce an executable in "/tmp/guix-build-lapack-3.9.0.drv-0/build/CMakeFiles/3.15.1/CompilerIdFortran". --8<---------------cut here---------------end--------------->8--- I do see an ‘a.out’ file in there, though. The code for that is in ‘CMakeDetermineCompilerId.cmake’: --8<---------------cut here---------------start------------->8--- # Find the executable produced by the compiler, try all files in the # binary dir. string(REGEX REPLACE "([][])" "[\\1]" _glob_id_dir "${CMAKE_${lang}_COMPILER_ID_DIR}") file(GLOB files RELATIVE ${CMAKE_${lang}_COMPILER_ID_DIR} # normal case ${_glob_id_dir}/* # com.apple.package-type.bundle.unit-test ${_glob_id_dir}/*.xctest/* # com.apple.product-type.framework ${_glob_id_dir}/*.framework/* ) list(REMOVE_ITEM files "${src}") set(COMPILER_${lang}_PRODUCED_FILES "") foreach(file ${files}) if(NOT IS_DIRECTORY ${CMAKE_${lang}_COMPILER_ID_DIR}/${file}) list(APPEND COMPILER_${lang}_PRODUCED_FILES ${file}) file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log "Compilation of the ${lang} compiler identification source \"" "${src}\" produced \"${file}\"\n\n") endif() endforeach() if(NOT COMPILER_${lang}_PRODUCED_FILES) # No executable was found. file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log "Compilation of the ${lang} compiler identification source \"" "${src}\" did not produce an executable in \"" "${CMAKE_${lang}_COMPILER_ID_DIR}\".\n\n") endif() --8<---------------cut here---------------end--------------->8--- Why would that fail? Mystery… There’s some code in CMake that looks at /proc/cpuinfo, so that could somehow make the wrong decision, but I don’t see how. Also, why would it affect emulation of ARMv7 but not emulation of AArch64, as seems to be the case? Ideas, people? Thanks, Ludo’.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.