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. The selftest code is modular enough that it's included in xfs_io and it seems to run in under 500us even on my ancient raspberry pi 3b+ downclocked to 600mhz. Why don't we just add it to mkfs and repair? Those tools shouldn't be run all that frequently, and now we'll know immediately if crc32c is broken on a user's system. Then we don't need the build-time selftest at all. --D > Helmut >
