Re: 01/06: gnu: llvm, clang: Update to 6.0.0.
Hi Marius,
mba...@fastmail.com (Marius Bakke) writes:
> mbakke pushed a commit to branch master
> in repository guix.
>
> commit 9bdbabe963e48bcac11c053a38d990873ca48dca
> Author: Marius Bakke
> Date: Sat Mar 31 22:04:44 2018 +0200
>
> gnu: llvm, clang: Update to 6.0.0.
Thanks for this, but ...
> + ;; Link to libclang_rt files from clang-runtime.
> + ;; This substitution needed slight adjustment in
> 3.8.
> + (if (< 3.8 (string->number ,(version-major+minor
> + (package-version
> +clang-runtime
> + (substitute* "lib/Driver/Tools.cpp"
> +(("TC\\.getDriver\\(\\)\\.ResourceDir")
> + (string-append "\"" compiler-rt "\"")))
> + (substitute* "lib/Driver/ToolChain.cpp"
> +(("getDriver\\(\\)\\.ResourceDir")
> + (string-append "\"" compiler-rt "\""
The version comparison code above is incorrect. This code will judge
version 3.10 to be older than 3.8.
'string->number' is never a sensible procedure to apply to version
numbers with more than one component, because it is not injective, let
alone order-preserving. For example, "3.1" and "3.10" map to the same
number 3.1, although they are different versions.
I suggest that you use 'version-compare', 'version>?', or 'version>=?'
from (guix utils). Note that these are not available to build-side
code, so the entire 'if' should be lifted to client-side code, which is
better anyway. Maybe something like this (untested):
;; Link to libclang_rt files from clang-runtime.
;; This substitution needed slight adjustment in 3.8.
,(let ((runtime-version (version-major+minor
(package-version
clang-runtime
(if (version>? runtime-version "3.8")
'(substitute* "lib/Driver/Tools.cpp"
(("TC\\.getDriver\\(\\)\\.ResourceDir")
(string-append "\"" compiler-rt "\"")))
'(substitute* "lib/Driver/ToolChain.cpp"
(("getDriver\\(\\)\\.ResourceDir")
(string-append "\"" compiler-rt "\"")
What do you think?
Mark
Re: Python applications that are also libraries
Am 06.04.2018 um 14:12 schrieb Ricardo Wurmus: > The point here is that in the library case inputs must be propagated, > whereas in the case where only the executables are used the inputs don’t > have to be propagated. > > Separating them in two outputs doesn’t address this problem as far as I > can see. Using the venv-based wrapper I describe in
Re: a blog post
Am 06.04.2018 um 10:58 schrieb Catonano: > It's about Guix, Guile and Free Software in general. From my very own > point of view Quote: [org.mode…] as far as I understand some Google employees worked on it. Does one become blessed and enlightened by getting employed by Gugle? Is Gugle a magic guild? Sorry, can't stand this google devoutness. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: a blog post
On 2018-04-07 11:53, Hartmut Goebel wrote: Am 06.04.2018 um 10:58 schrieb Catonano: It's about Guix, Guile and Free Software in general. From my very own point of view Quote: [org.mode…] as far as I understand some Google employees worked on it. Does one become blessed and enlightened by getting employed by Gugle? Is Gugle a magic guild? Who knows? Who cares? I wonder why you think this an appropriate reply to a blog post that clearly implies neither, and how it will influence people still considering writing about Guix. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
Re: a blog post
2018-04-07 11:53 GMT+02:00 Hartmut Goebel : > Am 06.04.2018 um 10:58 schrieb Catonano: > > It's about Guix, Guile and Free Software in general. From my very own > > point of view > > Quote: > > [org.mode…] as far as I understand some Google employees worked on it. > > Does one become blessed and enlightened by getting employed by Gugle? Is > Gugle a magic guild? > > Sorry, can't stand this google devoutness. > Hartmut, it's not devoutness What I was trying to convey is that org-mode reached a wide community, it entered places where the common attitude towards the gpl is of prudence, to say at least. I was not referring to a technological success but rather to a communitarian (political ?) one. Guile is light years far away from such a success, sadly. That said, I also expect the average Google engineer to be quite competent. But admittedly that's not by direct experience That's all ☺
[PATCHES] gnu: linux-libre: Update to 4.16
Hello Guix,
Here are preliminary patches to update to linux-libre-4.16. It works
well on my x86_64 GuixSD system on the 'core-updates' branch, but it's
not convenient for me to test it on 'master'.
I would be grateful to hear reports of testing this on 'master', and
also on 'armhf' systems.
One more thing: I had to add 'flex' and 'bison' as native-inputs because
the build system in 4.16 now concludes that they need to be re-run for
some reason. This could perhaps be avoided by adding a phase to touch
the generated files, but I didn't try it.
I think I'd prefer to add a phase to *delete* the generated files and
therefore _always_ run flex and bison, so that we are using source code
instead of trusting generated code from upstream.
What do you think?
Anyway, here are the patches. Test reports encouraged.
Mark
>From 56c4a6c1b07de98fca003911ec85736fef61fcc6 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Sat, 7 Apr 2018 02:19:34 -0400
Subject: [PATCH 1/2] gnu: linux-libre: Add flex and bison to native-inputs.
* gnu/packages/linux.scm (make-linux-libre)[native-inputs]: Add flex and
bison.
---
gnu/packages/linux.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index ebf463f94..33661e8f5 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -284,6 +284,8 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
("bc" ,bc)
("openssl" ,openssl)
("kmod" ,kmod)
+ ("flex" ,flex)
+ ("bison" ,bison)
;; On x86, build with GCC-7 for full retpoline support.
;; FIXME: Remove this when our default compiler has retpoline support.
,@(match (system->linux-architecture
--
2.16.3
>From 9a7c61cc1f559d7c6ce6f0b5066b791a74491d5c Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Sat, 7 Apr 2018 01:37:45 -0400
Subject: [PATCH 2/2] gnu: linux-libre: Update to 4.16.
* gnu/packages/linux.scm (%linux-libre-version): Update to 4.16.
(%linux-libre-hash): Update hash.
* gnu/packages/aux-files/linux-libre/4.15-arm.conf,
gnu/packages/aux-files/linux-libre/4.15-i686.conf,
gnu/packages/aux-files/linux-libre/4.15-x86_64.conf: Delete files.
* gnu/packages/aux-files/linux-libre/4.16-arm.conf,
gnu/packages/aux-files/linux-libre/4.16-i686.conf,
gnu/packages/aux-files/linux-libre/4.16-x86_64.conf: New files.
* Makefile.am (AUX_FILES): Update accordingly.
---
Makefile.am| 6 +-
.../linux-libre/{4.15-arm.conf => 4.16-arm.conf} | 181 ++-
.../linux-libre/{4.15-i686.conf => 4.16-i686.conf} | 252 +
.../{4.15-x86_64.conf => 4.16-x86_64.conf} | 250
gnu/packages/linux.scm | 4 +-
5 files changed, 438 insertions(+), 255 deletions(-)
rename gnu/packages/aux-files/linux-libre/{4.15-arm.conf => 4.16-arm.conf} (98%)
rename gnu/packages/aux-files/linux-libre/{4.15-i686.conf => 4.16-i686.conf} (98%)
rename gnu/packages/aux-files/linux-libre/{4.15-x86_64.conf => 4.16-x86_64.conf} (98%)
diff --git a/Makefile.am b/Makefile.am
index e647f270d..b56f7b3bc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -256,9 +256,9 @@ dist_noinst_DATA = guix/tests.scm guix/tests/http.scm
# Auxiliary files for packages.
AUX_FILES = \
gnu/packages/aux-files/emacs/guix-emacs.el \
- gnu/packages/aux-files/linux-libre/4.15-arm.conf \
- gnu/packages/aux-files/linux-libre/4.15-i686.conf \
- gnu/packages/aux-files/linux-libre/4.15-x86_64.conf \
+ gnu/packages/aux-files/linux-libre/4.16-arm.conf \
+ gnu/packages/aux-files/linux-libre/4.16-i686.conf \
+ gnu/packages/aux-files/linux-libre/4.16-x86_64.conf \
gnu/packages/aux-files/linux-libre/4.14-arm.conf \
gnu/packages/aux-files/linux-libre/4.14-i686.conf \
gnu/packages/aux-files/linux-libre/4.14-x86_64.conf \
diff --git a/gnu/packages/aux-files/linux-libre/4.15-arm.conf b/gnu/packages/aux-files/linux-libre/4.16-arm.conf
similarity index 98%
rename from gnu/packages/aux-files/linux-libre/4.15-arm.conf
rename to gnu/packages/aux-files/linux-libre/4.16-arm.conf
index ec1971472..484242917 100644
--- a/gnu/packages/aux-files/linux-libre/4.15-arm.conf
+++ b/gnu/packages/aux-files/linux-libre/4.16-arm.conf
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/arm 4.15.0-gnu Kernel Configuration
+# Linux/arm 4.16.0-gnu Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
@@ -25,7 +25,6 @@ CONFIG_FIQ=y
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
-CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
@@ -75,7 +74,6 @@ CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
-# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
@@ -245,6 +243,7 @@ CONFIG_HAVE_D
Re: [PATCHES] gnu: linux-libre: Update to 4.16
On Sat, Apr 07, 2018 at 02:36:04PM -0400, Mark H Weaver wrote: > One more thing: I had to add 'flex' and 'bison' as native-inputs because > the build system in 4.16 now concludes that they need to be re-run for > some reason. This could perhaps be avoided by adding a phase to touch > the generated files, but I didn't try it. I noticed this too while building 4.16 with Debian's tooling (`make bindeb-pkg`). > Anyway, here are the patches. Test reports encouraged. Thanks, I'm testing this on x86_64 (it's what I have access to). I noticed this warning at the beginning of the build phase: -- starting phase `build' scripts/kconfig/conf --silentoldconfig Kconfig Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel" -- The warning goes away when elfutils is available in the build environment. signature.asc Description: PGP signature
Re: [PATCHES] gnu: linux-libre: Update to 4.16
Leo Famulari writes: > On Sat, Apr 07, 2018 at 02:36:04PM -0400, Mark H Weaver wrote: >> One more thing: I had to add 'flex' and 'bison' as native-inputs because >> the build system in 4.16 now concludes that they need to be re-run for >> some reason. This could perhaps be avoided by adding a phase to touch >> the generated files, but I didn't try it. > > I noticed this too while building 4.16 with Debian's tooling (`make > bindeb-pkg`). That's interesting. I guess the timestamps in your unpacked source directory were probably not zeroed, so I guess that timestamps are not the issue here. >> Anyway, here are the patches. Test reports encouraged. > > Thanks, I'm testing this on x86_64 (it's what I have access to). > > I noticed this warning at the beginning of the build phase: > > -- > starting phase `build' > scripts/kconfig/conf --silentoldconfig Kconfig > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install > libelf-dev, libelf-devel or elfutils-libelf-devel" > -- > > The warning goes away when elfutils is available in the build > environment. Ah, good catch! I've now added to my queue another patch which adds elfutils to native-inputs in 'make-linux-libre'. I'll push it to master along with the 4.16 update after a bit more testing. Thanks, Mark
