On Sun, Nov 21, 2021 at 09:27:19AM +1100, Dave Chinner wrote: > On Sun, Nov 21, 2021 at 09:20:09AM +1100, Dave Chinner wrote: > > On Sat, Nov 20, 2021 at 09:15:48AM -0800, Darrick J. Wong wrote: > > > On Sat, Nov 20, 2021 at 08:32:40AM +0100, Helmut Grohne wrote: > > > > Hi Dave, > > > > > > > > On Sat, Nov 20, 2021 at 10:11:05AM +1100, Dave Chinner wrote: > > > > > I don't get it. The crcselftest does not use liburcu in > > > > > any way, nor does it try to link against liburcu, so it should not > > > > > fail because other parts of xfsprogs use liburcu. > > > > > > > > > > What's the build error that occurs? > > > > > > > > As the build log shows, that's not technically accurate. You can find > > > > logs of test builds for various architecture combinations at > > > > http://crossqa.debian.net/src/xfsprogs. This is also available as a link > > > > called "cross" in https://tracker.debian.org/xfsprogs. > > > > > > > > The relevant part is: > > > > | [TEST] CRC32 > > > > | In file included from crc32.c:35: > > > > | ../include/platform_defs.h:27:10: fatal error: urcu.h: No such file or directory > > > > | 27 | #include <urcu.h> > > > > | | ^~~~~~~~ > > > > | compilation terminated. > > > > > > > > I failed to figure a good way of dropping either include directive. > > > > > > > > > We need to fix the generic cross-build problem in the xfsprogs code, > > > > > not slap a distro-specific build band-aid over it. > > > > > > > > I fully agree with this in principle. However, when I fail to find that > > > > upstreamable solution, I try to at least provide a Debian-specific > > > > solution to iterate from. > > > > > > > > Can you propose a way to drop either #include? > > > > > > Frankly I don't really see the value in crc32selftest when cross > > > compiling -- sure, the crc32c code works correctly on the build host, > > > but that proves nothing about the (cross-)built binaries that end up in > > > the package. > > > > Yup, that's pretty much what I was getting at. > > Though this is pretty simple and should just work, too: > > --- a/libfrog/crc32.c > +++ b/libfrog/crc32.c > @@ -29,10 +29,11 @@ > * match the hardware acceleration available on Intel CPUs. > */ > > +#include <stdio.h> > +#include <sys/types.h> > #include <inttypes.h> > #include <asm/types.h> > #include <sys/time.h> > -#include "platform_defs.h" > /* For endian conversion routines */ > #include "xfs_arch.h" > #include "crc32defs.h" That works for my system, though I don't do cross builds frequently so I don't really know if it fixes those outside of my toy environment. I'll send a bigger patch to add selftest to mkfs/repair tomorrow. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
