emerge --info '=sys-fs/zfs-kmod-2.1.1::gentoo' - https://termbin.com/0c9rl emerge -pqv '=sys-fs/zfs-kmod-2.1.1::gentoo' - https://termbin.com/t7nl ebuild environment - https://termbin.com/nkmcs sys-fs/zfs-kmod build failed whith kernel, which compiled with clang. with kernel, which compiled with gcc sys-fs/zfs-kmod builds and installs without any problem.
Please attach the logs instead for posterity, thanks (compress if it complains about being too large).
Does this problem appear on ubuntu 20.04 LTS?
(In reply to Sam James from comment #1) > Please attach the logs instead for posterity, thanks (compress if it > complains about being too large). Please also include the missing build.log. Probably related to https://github.com/gentoo/gentoo/pull/22339.
Just use gcc lol
(In reply to Gtick Fleth from comment #4) > Just use gcc lol This isn't a helpful comment, please keep things like this off our bug tracker. Thanks.
Created attachment 740538 [details] build log
I'll check correct way of doing it. the PR version completely broke compilation under some configurations and broke cross compilation.
Mine for good measure: https://github.com/openzfs/zfs/pull/13046 Tested working with sys-fs/zfs-kmod-9999 against sys-kernel/gentoo-sources-5.16.3. Haven't tested with cross-compiling, though.
The PR was accepted upstream with https://github.com/openzfs/zfs/commit/b66140c6ad481cb13e685465c6a732f7f2b9dc77. There are now three environment variables that can be set to affect the module build. LINUX_CC is passed as $(CC), LINUX_LD as $(LD), and LINUX_LLVM as $(LLVM). A trivial example of how it can be used, at the end of pkg_setup(): > if tc-is-clang; then > ewarn "Warning: building ${PN} with a clang is experimental." > export KERNEL_CC="$(tc-getBUILD_CC)" > > if tc-ld-is-lld; then > export KERNEL_LD="$(tc-getBUILD_LD)" > > KERNEL_LLVM=1 > for tool in AR NM STRIP OBJCOPY READELF; do > [[ $(tc-getBUILD_${tool}) != *llvm-${tool,,} ]] && KERNEL_LLVM=0 > done > export KERNEL_LLVM > fi > fi
(In reply to Peter Levine from comment #9) > The PR was accepted upstream with > https://github.com/openzfs/zfs/commit/ > b66140c6ad481cb13e685465c6a732f7f2b9dc77. > > There are now three environment variables that can be set to affect the > module build. LINUX_CC is passed as $(CC), LINUX_LD as $(LD), and > LINUX_LLVM as $(LLVM). A trivial example of how it can be used, at the end > of pkg_setup(): > > > if tc-is-clang; then > > ewarn "Warning: building ${PN} with a clang is experimental." > > export KERNEL_CC="$(tc-getBUILD_CC)" > > > > if tc-ld-is-lld; then > > export KERNEL_LD="$(tc-getBUILD_LD)" > > > > KERNEL_LLVM=1 > > for tool in AR NM STRIP OBJCOPY READELF; do > > [[ $(tc-getBUILD_${tool}) != *llvm-${tool,,} ]] && KERNEL_LLVM=0 > > done > > export KERNEL_LLVM > > fi > > fi Oh, I'd forgot this was included in 2.1.3. Let's chuck it in.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b55c828e5df46717ed9eaecd18598eaaacab856 commit 7b55c828e5df46717ed9eaecd18598eaaacab856 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-03-11 12:31:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-11 12:31:04 +0000 sys-fs/zfs-kmod: add Clang logic The needed patch made its way upstream but we need a small amount of logic in the ebuild to accommodate it fully. Bug: https://github.com/openzfs/zfs/pull/13046 Closes: https://bugs.gentoo.org/814194 Thanks-to: Peter Levine <plevine457@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> sys-fs/zfs-kmod/zfs-kmod-2.1.3.ebuild | 18 ++++++++++++++++++ sys-fs/zfs-kmod/zfs-kmod-9999.ebuild | 18 ++++++++++++++++++ 2 files changed, 36 insertions(+)
Optimally feel linux-info/mod would need a *get_kernelCC / *set_kernel_toolchain or something like that (not that I've had interest in looking into this). That aside, you can skip the clang logic if `linux_chkconfig_present CC_IS_CLANG` is false, meaning the kernel wasn't built with clang. There's also LD_IS_LLD and LTO_CLANG_THIN which may be useful (the latter is because a thinlto kernel cause sandbox violations with cache last I tried it, but been a while). nvidia-drivers has some lazy logic which ignores tc-is-clang, not perfect but given it always failed on a clang-built kernel otherwise felt harmless to add.
(In reply to Ionen Wolkens from comment #12) > That aside, you can skip the clang logic if `linux_chkconfig_present > CC_IS_CLANG` is false, meaning the kernel wasn't built with clang. How ideally should one handle a case in which `linux_chkconfig_present CC_IS_CLANG` returns true but $(tc-getBUILD_CC) is gcc? die? Assume that "clang" corresponds to the executable that $(tc-getBUILD_CC) would have been at the time of the kernel build and pass that? Parse 'linux_chkconfig_present CLANG_VERSION' for a major version number and pass "clang-$MAJ_VER"?
(In reply to Peter Levine from comment #13) > How ideally should one handle a case in which `linux_chkconfig_present > CC_IS_CLANG` returns true but $(tc-getBUILD_CC) is gcc? die? Assume that > "clang" corresponds to the executable that $(tc-getBUILD_CC) would have been > at the time of the kernel build and pass that? Parse > 'linux_chkconfig_present CLANG_VERSION' for a major version number and pass > "clang-$MAJ_VER"? I meant parse $(linux_chkconfig_string CLANG_VERSION)
