Page MenuHomeFreeBSD

ZFS: Unbreak the world build on CURRENT with the OpenZFS import
ClosedPublic

Authored by neel_neelc.org on Aug 25 2020, 5:42 PM.

Details

Summary

ZFS: Unbreak the world build on CURRENT with the OpenZFS import at r364746.

Submitted by: Neel Chauhan <neel AT neelc DOT org>

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

neel_neelc.org retitled this revision from ZFS: Unbreak the lz4 build on CURRENT with the OpenZFS import to ZFS: Unbreak the world build on CURRENT with the OpenZFS import.Aug 25 2020, 5:47 PM
neel_neelc.org edited the summary of this revision. (Show Details)

@neel_neelc.org can you tell me a bit more about your environment, make universe builds for all of us and only the powerpcspe tinderbox is currently broken because of these changes. I'm happy to commit these changes I just want to know what it's fixing.

This patch fixes the build issue complaining about:

#include <lz4.h>

not being "lz4"

and

#define	ASSERT

being #define'd twice

This is an older Haswell homebuilt PC running 13-CURRENT amd64.

It could also be an older copy of clang/llvm.

This is the error I get without the patch:

/usr/src/sys/cddl/contrib/opensolaris/common/lz4/lz4.c:55:9: error: 'ASSERT' macro redefined [-Werror,-Wmacro-redefined]
#define ASSERT  assert
        ^
/usr/src/sys/contrib/openzfs/lib/libspl/include/assert.h:138:9: note: previous definition is here
#define ASSERT          VERIFY
        ^
/usr/src/sys/cddl/contrib/opensolaris/common/lz4/lz4.c:57:10: error: 'lz4.h' file not found with <angled> include; use "quotes" instead
#include <lz4.h>
         ^~~~~~~
         "lz4.h"
This revision is now accepted and ready to land.Aug 25 2020, 9:43 PM
This comment was removed by mmacy.

I will apply your patch, but it's a bit silly to call that "breaking world". -There's no guarantee that -DNO_CLEAN or -DNO_KERNELCLEAN will work across major changes.

This revision was automatically updated to reflect the committed changes.

I've been able to keep a NO_CLEAN tree going for several years; it does break occasionally but we have a standard, if ugly, way of addressing the resulting dependency issues when they occur.