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)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b66ebce8f979c5dfc190070c22745b7aa375cc3 commit 7b66ebce8f979c5dfc190070c22745b7aa375cc3 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-05-24 00:03:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-30 02:50:53 +0000 sys-fs/zfs-kmod: migrate to linux-mod-r1 (sam: Taking ionen's PoC conversion and committing it after testing.) Closes: https://bugs.gentoo.org/814194 Closes: https://bugs.gentoo.org/865157 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> sys-fs/zfs-kmod/files/zfs-kmod-2.1.11-gentoo.patch | 24 +++ sys-fs/zfs-kmod/zfs-kmod-2.1.11-r1.ebuild | 197 +++++++++++++++++++++ 2 files changed, 221 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=daa1294b8328bec24e5ef525bf60be71bbab0f15 commit daa1294b8328bec24e5ef525bf60be71bbab0f15 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-30 02:40:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-30 02:51:32 +0000 sys-fs/zfs-kmod: sync live Bug: https://bugs.gentoo.org/814194 Bug: https://bugs.gentoo.org/865157 Signed-off-by: Sam James <sam@gentoo.org> sys-fs/zfs-kmod/zfs-kmod-9999.ebuild | 141 +++++++++++++---------------------- 1 file changed, 51 insertions(+), 90 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1b0b98a5615b84018cc7af5c47206fc4f7d64c9a commit 1b0b98a5615b84018cc7af5c47206fc4f7d64c9a Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-05-24 16:33:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-30 02:51:20 +0000 sys-fs/zfs-kmod: further linux-mod-r1 adaptations & style tweaks Just meant to integrate MODULES_KERNEL_MIN+MAX ended up making quick changes to my liking while at it. Thus the separate commit (also is barely tested changes). Probably can still use polishing. MAX is non-fatal, but gives a very large warning that is hard to miss, imo removing the need for a hidden override variable. Made optional for dist-kernel through another USE so people can still get automated rebuilds if they e.g. patched it (pondered adding a similar mechanism builtin the eclass but believe too few ebuilds really need this and don't want to encourage it globally unless really needed). wrt <virtual/dist-kernel, haven't looked into the history of it but right now can't quite see why it need to be BDEPEND, regardless of it existing in the eclass portage will have to respect the extra bound in RDEPEND as this isn't a || ( ). Or at least, it's not trying to upgrade my kernel here and I get the usual "WARNING:" that it can't upgrade (on a side-note, don't need to repeat the := given the eclass' is still valid). (sam: preserved ionen's original commit msg for posterity but obviously tested it and reviewed it since. We discussed the cap situation and concluded it's probably best for now to stick with it as-is (in this commit) given +dist-kernel-cap handles it for most cases, and if not using dist-kernel, you may not want things managed for you anyway.) Bug: https://bugs.gentoo.org/814194 Bug: https://bugs.gentoo.org/865157 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> sys-fs/zfs-kmod/metadata.xml | 1 + sys-fs/zfs-kmod/zfs-kmod-2.1.11-r1.ebuild | 106 ++++++++++-------------------- 2 files changed, 37 insertions(+), 70 deletions(-)
