| Summary: | r365715: OpenZFS: buildkernel failure: ld: error: undefined symbol: dataset_kstats_destroy | ||
|---|---|---|---|
| Product: | Base System | Reporter: | O. Hartmann <ohartmann> |
| Component: | kern | Assignee: | Allan Jude <allanjude> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | Trond.Endrestol, allanjude, emaste, kib, markj |
| Priority: | --- | ||
| Version: | 12.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
O. Hartmann
2020-09-14 13:29:01 UTC
Just an add on: GENERIC kernel fails the same way. I got the same failure on my stable/12 builder at work, two nights in a row. My builder tries to compile world and 10 (custom) kernels, including GENERIC, every night. Judging by the commit log, r365689 might be the culprit. I use meta mode and -D NO_CLEAN. If the coming night's attempt to build stable/12 fails in the same manner, I'm tempted to blow away the kernel subdirectories. (In reply to Trond.Endrestol from comment #2) Blowing away the kernel subdirectories in the object tree serves no purposes, I discovered on an experimental system also running stable/12. Reverting to r365688 made the kernels build successfully again. While we usually statically compile in "options ZFS" into the kernel, I tried commenting out this option. Now, I got rid of the error. We saw this behaviour on CURRENT recently and there it has been fixed. (In reply to O. Hartmann from comment #4) I added allanjude@ to the Cc list as he committed r365689. Allan, would it be possible to add the necessary Makefile logic to allow options ZFS in stable/12? A commit references this bug: Author: allanjude Date: Wed Sep 16 20:58:24 UTC 2020 New revision: 365808 URL: https://svnweb.freebsd.org/changeset/base/365808 Log: Connect new ZFS source file to the kernel build This was missed in r365689 This causes compile issues when building ZFS into the kernel PR: 249311 MFC-with: r365689 Sponsored by: Klara Inc. Changes: stable/12/sys/conf/files (In reply to commit-hook from comment #6) Wonderful. Thank you, Allan. I'll do a test later this evening. (In reply to Trond.Endrestol from comment #7) I just upgraded an experimental system now running amd64 stable/12 r365834, where options ZFS, device dtrace, and device dtraceall goes in the mix. (In reply to Trond.Endrestol from comment #8) I was unclear. The attempt was successful. Oliver, do you see the same behaviour? Is this PR resolved? (In reply to Mark Johnston from comment #10) Yes, unless Oliver objects. Closing fixed in the absence of feedback, please feel free to re-open. |