Arch Linux User Repository

Hey there! I'm working on a program that uses Chez Scheme, written in Rust (which, at least on my configuration, by default uses ld.lld) and I'm having problems with this package due to the use of --kernelobj. The issue is that kernel.o is built with GCC LTO, which is (currently) impossible to link using ld.lld.

There are a few options I see towards solving this, in decreasing order of my preference:

1. Use --libkernel and let downstream users deal with linking with a static library rather than just an object file. Looking at a few other package repositories (Debian, Fedora, NixOS) I find that using --kernelobj is quite nonstandard, so many downstream users would already expect a libkernel.a, I would think. EDIT: This would also require disabling LTO or fat LTO objects, but would still be more standard in my opinion.

2. Enable -ffat-lto-objects: ./configure [...] CFLAGS+=-ffat-lto-objects

3. Disable LTO entirely: options=(!lto) in the PKGBUILD

@williewillus Thanks for the heads up. I'm double-checking on my end, but so far it indeed seems to be building without any issue. I'll push the new version when the build has completed.

10.3.0 came out a couple weeks ago, looks like substituting 10.3.0 into the PKGBUILD and running ./build works fine.

@envolution done, and updated to 10.2.0.

@Ponas could you please try rebuilding with 10.2.0? Afaict, this is a combination of gcc15 adding further checks and chez-scheme building with -Werror by default. The 10.2.0 release seems to have adjusted/fixed the offending code. Alternatively, if you must use 10.1.0, you can stop gcc treating that warning as an error by appending CFLAGS+='-Wno-error=incompatible-pointer-types' to the configure invocation in the PKGBUILD and retrying the build.

@ecraven apologies for taking so long to get around to this, --kernelobj is being used for 10.2.0.

gcc -march=native -mtune=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DZUO_LIB_PATH='"'".././zuo/lib"'"' -o bin/zuo ./zuo/zuo.c ./zuo/zuo.c: In function ‘zuo_init_signal_handler’: ./zuo/zuo.c:5585:17: error: assignment to ‘__sighandler_t’ {aka ‘void ()(int)’} from incompatible pointer type ‘void ()(void)’ [-Wincompatible-pointer-types] 5585 | sa.sa_handler = zuo_signal_received; | ^ ./zuo/zuo.c:5565:13: note: ‘zuo_signal_received’ declared here 5565 | static void zuo_signal_received() { | ^ In file included from /usr/include/sys/wait.h:36, from ./zuo/zuo.c:23: /usr/include/signal.h:72:16: note: ‘__sighandler_t’ declared here 72 | typedef void (*__sighandler_t) (int); | ^~~~ make: *** [Makefile:167: bin/zuo] Error 1 ==> ERROR: A failure occurred in build(). Aborting... error: failed to build 'chez-scheme-10.1.0-1'

can you please remove 'replaces chez-scheme-git' as per https://wiki.archlinux.org/title/AUR_submission_guidelines - 1.1

it has also been updated: https://aur.archlinux.org/packages/chez-scheme-git

@maoif Thanks for raising this. Should be updated now.

@ecraven That definitely sounds like it would be good to have. It seems like it should be on by default (https://github.com/cisco/ChezScheme/commit/be33b28cff859ec3580a0435f4622c0218d70a38) ? Unless I am missing something. If turns out it is no longer on by default, so long as nobody else has any objections — I'll wait ~2 weeks and see — I'll update the PKGBUILD and revision.

Could you be persuaded to add --kernelobj to the ./configure line? This would also build several additional files that won't hurt, but are necessary to use https://github.com/gwatt/chez-exe (which is great for creating stand-alone executables with chez).

@taekyung Ah sorry! Didn't mean to snipe your work

Afaict based on the GH repo, x11 is necessary for more than just the docs 1,2. But there is a --disable-x11 flag which we could add to the configure script 3 and then cut that dependency (or move it to an optdepends)? : )

re: glibc -- I think that should definitely be on there as it probably won't build or run without it. I don't actually know if you could have the build tools necessary without also having glibc installed, but since Chez requires it, it should be listed as a dependency imo