Page MenuHomeFreeBSD

Fix -Werror,-Wmacro-redefined when building with CROSS_TOOLCHAIN=llvm10
AbandonedPublic

Authored by arichardson on Aug 26 2020, 3:37 PM.
Tags
None
Referenced Files
F81580122: D26196.diff
Thu, Apr 18, 10:44 AM
Unknown Object (File)
Dec 22 2023, 1:05 PM
Unknown Object (File)
Dec 20 2023, 5:11 AM
Unknown Object (File)
Nov 14 2023, 9:29 PM
Unknown Object (File)
Jun 24 2023, 7:02 AM
Unknown Object (File)
Jun 24 2023, 3:57 AM
Unknown Object (File)
May 6 2023, 9:33 AM
Unknown Object (File)
Mar 4 2023, 11:17 AM
Subscribers

Details

Reviewers
mmacy
freqlabs
Group Reviewers
ZFS
Summary

Those macros are also defined by the compiler-provided float.h which will be
included later on and trigger these warnings. Include <float.h> first and only
define the macros when missing to fix this problem.

Diff Detail

Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 33172
Build 30521: arc lint + arc unit

Event Timeline

Upload correct version of patch

Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?

Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?

Changes to contrib should always be made in the following order when possible:
a) update upstream
b) update vendor branch with latest changeset
c) merge vendor branch in to HEAD

Thus the first step is to open a PR with openzfs.

We may eventually relax the ordering if this proves too onerous for something as tightly coupled as ZFS and transition to "eventual consistency" whereby contrib + vendor + upstream are eventually the same.

Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?

Changes to contrib should always be made in the following order when possible:
a) update upstream
b) update vendor branch with latest changeset
c) merge vendor branch in to HEAD

Thus the first step is to open a PR with openzfs.

We may eventually relax the ordering if this proves too onerous for something as tightly coupled as ZFS and transition to "eventual consistency" whereby contrib + vendor + upstream are eventually the same.

Sounds like a good plan, thanks Matt.