Summary: | dev-scheme/guile-3.0.4 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Scheme Project <scheme> |
Status: | IN_PROGRESS --- | ||
Severity: | normal | CC: | anton.kochkov, manday, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=746914 https://bugs.gentoo.org/show_bug.cgi?id=768915 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
guile-3.0.0-stack-grows-up.patch
.ebuild for 3.0.4 - patch in FILES renamed accordingly |
(cont.) - The prebuilt issue from bug #676468 was not fixed in this release. This would also require a sub-SLOT (or better yet, a normal SLOT, see bug #689408). There 3.0.1 bugfix release also https://www.gnu.org/software/guile/news/gnu-guile-301-released.html > Among the bug fixes is a significant performance improvement for applications making heavy use of bignums, such as the compiler. Also included are fixes for an embarrassing bug in the `include` directive, for the `hash` procedure when applied to keywords and some other objects, portability fixes, and better R7RS support. https://lists.gnu.org/archive/html/guile-devel/2020-03/msg00012.html This patch is not required with the 3.0.2 I believe, so the keyword might be removed. Can we please just update to the current 3 release before being concerned with the finer details and subtle issues that might arise? Created attachment 663853 [details]
.ebuild for 3.0.4 - patch in FILES renamed accordingly
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48d334d335e508843e01686e55cdf5ca3beec366 commit 48d334d335e508843e01686e55cdf5ca3beec366 Author: Sam James <sam@gentoo.org> AuthorDate: 2020-10-05 20:05:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-10-05 20:07:02 +0000 dev-scheme/guile: bump to 3.0.4 (masked) Masking this for testing in case of compatibility problems. Guile is not slotted right now, so committing unmasked initially could mean various packages breaking. Bug: https://bugs.gentoo.org/705554 Bug: https://bugs.gentoo.org/689408 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Sam James <sam@gentoo.org> dev-scheme/guile/Manifest | 1 + dev-scheme/guile/guile-3.0.4.ebuild | 72 +++++++++++++++++++++++++++++++ profiles/arch/amd64/package.use.mask | 5 +++ profiles/arch/arm/armv7a/package.use.mask | 6 +++ profiles/arch/arm64/package.use.mask | 5 +++ profiles/arch/base/package.use.mask | 5 +++ profiles/arch/x86/package.use.mask | 6 +++ profiles/package.mask | 7 +++ 8 files changed, 107 insertions(+) Among other things guile-3 allows library loading by their absolute name (for gentoo's zlib it's the only option to make it work at all): $ guile -c '(dynamic-link "/lib64/libz.so.1")' <ok> guile-2 has no equivalent interface: $ guile -c '(dynamic-link "/lib64/libz.so.1")' Backtrace: 5 (apply-smob/1 #<catch-closure 7f682ca25240>) In ice-9/boot-9.scm: 705:2 4 (call-with-prompt ("prompt") #<procedure 7f682ca3e720 …> …) In ice-9/eval.scm: 619:8 3 (_ #(#(#<directory (guile-user) 7f682c69a140>))) In ice-9/command-line.scm: 181:18 2 (_ #<input: string 7f682c6b8a80>) In unknown file: 1 (eval (dynamic-link "/lib64/libz.so.1") #<directory (gu…>) 0 (dynamic-link "/lib64/libz.so.1") ERROR: In procedure dynamic-link: In procedure dynamic-link: file: "/lib64/libz.so.1", message: "file not found" Lack of direct library loading makes it hard to package guile-zlib (a dependency of guix). Any updates on this? What needs to be done? (In reply to contact from comment #9) > Any updates on this? What needs to be done? - guile eclass to pick proper guile version for build and runtime - proper SLOTting a'la python_compat - testing if any builds break So, quite a lot, because of stale packages depending on guile 2.0, see: https://bugs.gentoo.org/746914 |
Created attachment 603442 [details, diff] guile-3.0.0-stack-grows-up.patch Guile 3.0.0 has been released with a long list of changes and probably some backward compatibility problems. - It left a stack direction problem in continuations.c on architectures where the stack grows up, for which a patch is attached. - It adds JIT support for some architectures but not others, which should be enabled through IUSE=jit (it can be left to automatic detection, too).