Page MenuHomeFreeBSD

libzpool: Set -Wno-error=typedef-redefinition for clang
ClosedPublic

Authored by ivy on Apr 27 2026, 3:49 AM.
Tags
None
Referenced Files
F158009415: D56653.id.diff
Wed, May 27, 11:07 AM
Unknown Object (File)
Wed, May 27, 6:29 AM
Unknown Object (File)
Tue, May 26, 9:19 PM
Unknown Object (File)
Mon, May 18, 12:37 PM
Unknown Object (File)
Mon, May 18, 12:29 PM
Unknown Object (File)
Mon, May 18, 11:32 AM
Unknown Object (File)
Mon, May 18, 11:25 AM
Unknown Object (File)
Sat, May 16, 9:59 PM
Subscribers

Details

Summary

In some versions of LLVM (at least 21), the <*intrin.h> headers contain
unguarded duplicate typedefs; this isn't permitted prior to C11, and
libzpool is built as C99. FreeBSD's LLVM backported LLVM PR #153820
to fix this, but other versions of LLVM (e.g., upstream, or on Linux)
don't have the patch, so this breaks the build.

Add -Wno-error=typedef-redefinition to downgrade this from an error
to a warning.

Sponsored by: https://www.patreon.com/bsdivy

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 72561
Build 69444: arc lint + arc unit

Event Timeline

ivy requested review of this revision.Apr 27 2026, 3:49 AM

If this doesn't happen too often across the tree, I'm fine with this approach. If there are more, it may make sense to put a generic macro (e.g. NO_WTYPEDEF_REDEFINITION) in bsd.sys.mk, like we have done for some other annoying warnings.

This revision is now accepted and ready to land.Apr 27 2026, 11:32 AM
In D56653#1297844, @dim wrote:

If this doesn't happen too often across the tree, I'm fine with this approach. If there are more, it may make sense to put a generic macro (e.g. NO_WTYPEDEF_REDEFINITION) in bsd.sys.mk, like we have done for some other annoying warnings.

this is the only case i found when testing this, and the only other existing use is in tools/build/mk/Makefile.boot which is a little special, so i think we're fine just inlining this here. i do wonder if we couldn't instead build OpenZFS as C17 like the rest of the system...

build OpenZFS as C17 like the rest of the system

We probably could, but I assume we're just following what upstream does.