bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[宋文武]

if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
libraries files to $out/lib64.

if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
find cmake modules of inputs.

I find this when packaging https://github.com/lxdg/libqtxdg.

bug#18933: ATLAS fails to build on mips

[Andreas Enge]

ATLAS fails to build on mipsel64:
   http://hydra.gnu.org/build/133025
with
mkdir ARCHS
make -f Make.top startup
make[1]: Entering directory '/tmp/nix-build-atlas-3.10.2.drv-0/build'
Make.top:1: Make.inc: No such file or directory
make[1]: *** No rule to make target 'Make.inc'.  Stop.
make[1]: Leaving directory '/tmp/nix-build-atlas-3.10.2.drv-0/build'

Can this be repaired, or is the package not supposed to work on mipsel64?
In the latter case, we would need to disable it for this architecture.

Andreas

bug#17201: xf86-input-evdev fails to build

[Andreas Enge]

This has been fixed in commit 4e3a820bfdf61cbc5be2ceb0ed8187f0066c6e97.

Andreas

bug#18741: xf86-video-ati fails to build on all platforms

[Andreas Enge]

The problem occurred at some point between
2014-08-31:
   http://hydra.gnu.org/build/84666
and 2014-09-22:
   http://hydra.gnu.org/build/95398

Andreas

bug#18740: xf86-video-openchrome fails to build on all platforms

[Andreas Enge]

The problem occurred between
2014-09-01:
   http://hydra.gnu.org/build/84728
and 2014-09-23:3.16.3.
   http://hydra.gnu.org/build/97172

In between we updated linux-libre twice (to 3.16.3 and 3.16.3),
and glibc to 2.20.

Andreas

bug#18741: xf86-video-ati fails to build on all platforms

[Andreas Enge]

Switching from 6.14.4 to 6.14.6 solves the problem. I suggest to do so
although we are leaving R7.7; keeping with the same minor version should be
safe (I also tried the latest version 7.5.0, but it requires a newer mesa).

Andreas

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[宋文武]

Ludovic Courtès  writes:

> 宋文武  skribis:
>
>> if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
>> libraries files to $out/lib64.
>
> I found several CMake-built libraries on x86_64 (graphite2, openjpeg,
> qjson) that all use lib/, not lib64/.
>
> Then I found one counterexample, libftdi; however, setting
> CMAKE_INSTALL_LIBDIR=lib doesn’t make any different: it still installs
> libraries in $out/lib64.  Any idea?
libftdi (not using GNUInstallDirs.cmake) handle this itself by
set LIB_SUFFIX, look like we have to set it specifically.
>
> Here’s the patch I tried:
>
> diff --git a/guix/build/cmake-build-system.scm 
> b/guix/build/cmake-build-system.scm
> index 74b4f01..b1598dd 100644
> --- a/guix/build/cmake-build-system.scm
> +++ b/guix/build/cmake-build-system.scm
> @@ -53,6 +53,8 @@
>   build-type))
>  '())
>,(string-append "-DCMAKE_INSTALL_PREFIX=" out)
> +  ;; Install libraries to $prefix/lib, not $prefix/lib64.
> +  "-DCMAKE_INSTALL_LIBDIR=lib"
>;; add input libraries to rpath
>"-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE"
>;; add (other) libraries of the project itself to rpath
>
> According to ,
> LIBRARY_OUTPUT_PATH might be better for this, no?
no, this is for build phase.
>
>> if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
>> find cmake modules of inputs.
>
> You’re talking about .cmake files, right?
yes, but now I find out that they can under both lib/cmake and share/cmake.
>
> Could you try the attached patch and report back?
>
> From 536c143997fa146dc77d6e8defc24032452e5a4c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> Date: Sun, 2 Nov 2014 23:54:28 +0100
> Subject: [PATCH] gnu: cmake: Add search paths for
>  CMAKE_{INCLUDE,LIBRARY,MODULE}_PATH.
>
> * gnu/packages/cmake.scm (cmake)[native-search-paths]: New field.
> * guix/build/cmake-build-system.scm (configure): Remove 'setenv' calls
>   for "CMAKE_LIBRARY_PATH" and "CMAKE_INCLUDE_PATH".
> ---
>  gnu/packages/cmake.scm| 19 +++
>  guix/build/cmake-build-system.scm |  2 --
>  2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/cmake.scm b/gnu/packages/cmake.scm
> index 63805ef..e0349be 100644
> --- a/gnu/packages/cmake.scm
> +++ b/gnu/packages/cmake.scm
> @@ -100,6 +100,25 @@
> ("expat"  ,expat)
> ("bzip2"  ,bzip2)
> ("libarchive" ,libarchive)))
> +
> +(native-search-paths
> + (list
> +  ;; Search path used by the 'FIND_XXX' functions.
> +  (search-path-specification
> +   (variable "CMAKE_PROGRAM_PATH")
> +   (directories '("bin")))
> +  (search-path-specification
> +   (variable "CMAKE_INCLUDE_PATH")
> +   (directories '("include")))
> +  (search-path-specification
> +   (variable "CMAKE_LIBRARY_PATH")
> +   (directories '("lib" "lib64")))
> +
> +  ;; Search path used by 'FIND_PACKAGE' and 'INCLUDE'.
> +  (search-path-specification
> +   (variable "CMAKE_MODULE_PATH")
> +   (directories '("lib/cmake")
> +
>  (home-page "http://www.cmake.org/";)
>  (synopsis "Cross-platform build system")
>  (description
> diff --git a/guix/build/cmake-build-system.scm 
> b/guix/build/cmake-build-system.scm
> index b1598dd..766797e 100644
> --- a/guix/build/cmake-build-system.scm
> +++ b/guix/build/cmake-build-system.scm
> @@ -60,8 +60,6 @@
>;; add (other) libraries of the project itself to rpath
>,(string-append "-DCMAKE_INSTALL_RPATH=" out "/lib")
>,@configure-flags)))
> -  (setenv "CMAKE_LIBRARY_PATH" (getenv "LIBRARY_PATH"))
> -  (setenv "CMAKE_INCLUDE_PATH" (getenv "CPATH"))
>(format #t "running 'cmake' with arguments ~s~%" args)
>(zero? (apply system* "cmake" args)
>  
> -- 
> 2.1.2
thanks for the patch, I have apply it, but it does not work.
because libqtxdg have qtxdg-config.cmake in $out/share/cmake/qt5xdg.

after add CMAKE_PREFIX_PATH with:

  (search-path-specification
(variable "CMAKE_PREFIX_PATH")
(directories '("")))

I could get liblxqt(use libqtxdg) build ok.

and by setting CMAKE_PREFIX_PATH, I think we can get rid of
CMAKE_PROGRAM_PATH, CMAKE_INCLUDE_PATH, and maybe CMAKE_LIBRARY_PATH.
see: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html.
>
>
>> I find this when packaging https://github.com/lxdg/libqtxdg.
>
> It’s 404.
oh, sorry, it's https://github.com/lxde/libqtxdg

and here is the packages I'm working on:


lxqt.scm
Description: Binary data

bug#18935: gexp->derivation test failure

[Mark H Weaver]

On my i686 standalone Guix system, using Guix v0.7-642-g3b50925 to build
its 'guix' package (0.7.14e84b2) fails, due to a failed test.  Here's
the relevant section from gexp.log:

--8<---cut here---start->8---
Test begin:
  test-name: "gexp->derivation"
  source-file: "tests/gexp.scm"
  source-line: 227
  source-form: (test-assert "gexp->derivation" (run-with-store %store (mlet* 
%store-monad ((file (text-file "foo" "Hello, world!")) (exp -> (gexp (begin 
(mkdir (ungexp output)) (chdir (ungexp output)) (symlink (string-append (ungexp 
%bootstrap-guile) "/bin/guile") "foo") (symlink (ungexp file) (ungexp output 
"2nd") (drv (gexp->derivation "foo" exp)) (out -> (derivation->output-path 
drv)) (out2 -> (derivation->output-path drv "2nd")) (done (built-derivations 
(list drv))) (refs ((store-lift references) out)) (refs2 ((store-lift 
references) out2)) (guile (package-file %bootstrap-guile "bin/guile"))) (return 
(and (string=? (readlink (string-append out "/foo")) guile) (string=? (readlink 
out2) file) (equal? refs (list (dirname (dirname guile (equal? refs2 (list 
file) #:guile-for-build (%guile-for-build)))
Test end:
  result-kind: fail
  actual-value: #f
  actual-error: (srfi-34 #)
--8<---cut here---end--->8---

The 'guix-daemon' used to do this failed build is also 0.7.14e84b2.

The 'guix' used to do this failed build was v0.7-642-g3b50925 plus one
local patch that adds
"--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt" to
the GnuTLS configure flags.

  Mark

bug#18926: cmake-build-system should set CMAKE_INSTALL_LIBDIR and CMAKE_PREFIX_PATH

[Ludovic Courtès]

宋文武  skribis:

> Ludovic Courtès  writes:
>
>> 宋文武  skribis:
>>
>>> if CMAKE_INSTALL_LIBDIR not set to `lib`, GNUInstallDirs.cmake will install
>>> libraries files to $out/lib64.
>>
>> I found several CMake-built libraries on x86_64 (graphite2, openjpeg,
>> qjson) that all use lib/, not lib64/.
>>
>> Then I found one counterexample, libftdi; however, setting
>> CMAKE_INSTALL_LIBDIR=lib doesn’t make any different: it still installs
>> libraries in $out/lib64.  Any idea?
> libftdi (not using GNUInstallDirs.cmake) handle this itself by
> set LIB_SUFFIX, look like we have to set it specifically.

Ah, OK.

Still, graphite2, openjpeg, and qjson all install to $prefix/lib, even
when not passing CMAKE_INSTALL_LIBDIR=lib.  Is it really needed?

>>> if CMAKE_PREFIX_PATH not set to PATH of `inputs`, cmake will unable to
>>> find cmake modules of inputs.
>>
>> You’re talking about .cmake files, right?
> yes, but now I find out that they can under both lib/cmake and share/cmake.

In that case...

>> +  ;; Search path used by 'FIND_PACKAGE' and 'INCLUDE'.
>> +  (search-path-specification
>> +   (variable "CMAKE_MODULE_PATH")
>> +   (directories '("lib/cmake")
^
... just add "share/cmake" here. ---’

Could you try that?

> after add CMAKE_PREFIX_PATH with:
>
>   (search-path-specification
> (variable "CMAKE_PREFIX_PATH")
> (directories '("")))

I thought about it, but that "" is inelegant and not as clear.

> and here is the packages I'm working on:

Looks like a good start.  :-)

Thanks,
Ludo’.

bug#18933: ATLAS fails to build on mips

[Federico Beffa]

What I see is that ATLAS is not able to detect the type of system on
which it is running.

My first question then is:

* Are we corss-compiling, or are we on proper hardware?

If we are cross-compiling, then the only solution that I see it to try
to fix the configuration with parameters passed to configure and give
up on optimization.

I have no practical experience with MIPS, so my next question is: In
the list of architectures supported by ATLAS I see:

49 = 'MIPSR1xK'
50 = 'MIPSICE9'

Is one of the two appropriate?

Also ATLAS wants to know about ISA extensions. Is any of the following
relevant or should I pick 'none'?

 none: 1
  VSX: 2
  AltiVec: 4
   AVXMAC: 8
  AVXFMA4: 16
  AVX: 32
 SSE3: 64
 SSE2: 128
 SSE1: 256
3DNow: 512
 NEON: 1024

Regards,
Fede

P.S.: I'm indeed not subscribed to the bug list. Could you copy me directly?

bug#18933: ATLAS fails to build on mips

[Andreas Enge]

On Mon, Nov 03, 2014 at 06:53:35PM +0100, Federico Beffa wrote:
> * Are we corss-compiling, or are we on proper hardware?

No, it is native on a mips machine.

> I have no practical experience with MIPS, so my next question is: In
> the list of architectures supported by ATLAS I see:
> 49 = 'MIPSR1xK'
> 50 = 'MIPSICE9'

No idea. But there is a debian package for mipsel, described as
"The libraries in this package are built without any processor extension 
instructions, and should run on all processors of this general architecture, 
albeit less than optimally."

> Also ATLAS wants to know about ISA extensions. Is any of the following
> relevant or should I pick 'none'?
>  none: 1
>   VSX: 2
>   AltiVec: 4
>AVXMAC: 8
>   AVXFMA4: 16
>   AVX: 32
>  SSE3: 64
>  SSE2: 128
>  SSE1: 256
> 3DNow: 512
>  NEON: 1024

2 and 4 are for powerpc, 8 to 512 for x86 and 1024 for arm. So "none"
should be best.

Andreas