Hi Eric On Wed, 7 Sep 2016 17:40:01 -0500 Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 9/7/16 5:27 PM, Dave Chinner wrote: > > On Wed, Sep 07, 2016 at 11:42:56AM +0200, Ralph Sennhauser wrote: > >> To get xfsprogs to cross-compile for musl some hacks were needed. > >> > >> 1) d_namlen isn't available with musl > > > > musl problem. It needs to define _DIRENT_HAVE_D_RECLEN and friends > > to tell applications what the struct dirent it defines contains. > > > > (Haven't we been through this before?) > > (yes: http://www.openwall.com/lists/musl/2016/01/15/9) > > what *does* it contain? > > We do already have: > > #ifdef _DIRENT_HAVE_D_RECLEN > *total += dirent->d_reclen; > #else > *total += dirent->d_namlen + sizeof(*dirent); > #endif > > but you'd like: > > #ifdef _DIRENT_HAVE_D_RECLEN > *total += dirent->d_reclen; > #else > - *total += dirent->d_namlen + sizeof(*dirent); > + *total += strlen(dirent->d_name) + sizeof(*dirent); > #endif > > but musl *does* have d_reclen: > > http://git.musl-libc.org/cgit/musl/tree/include/dirent.h > > so if it simply advertised that fact we'd be good... Why not test for d_reclen in configure instead? > > Whatever happened to that request from January above? > > That said, I suppose strlen is fine to use here, so I guess I don't > see a strong reason to object to this change. > Guessing uClibc would benefit as well. So how does testing for d_reclen and making the slow-path more portable by using strlen sound for a plan? > >> 2) crc32selftest doesn't make sense in case of cross-compilation, > >> the same can be said if building for a different host with the > >> native toolchain. So maybe an --disable-crc32selftest configure > >> option could be used here. > >> > >> 3) The CFLAGS passed to BUILD_CC weren't understood by the native > >> compiler. Set BUILD_CFLAGS to CFLAGS if not cross-compiling or let > >> it blank anyway? > > > > Ah, yes, we've definitely been through this before. Last time I said > > "send patches" and they never appeared. Well this is a case of easy to write the code but hard to figure out what the upstream preferred way of handling it is. I'd just put it behind a test target. Distribution developers are conditioned to run make test. > > > > As it is, I'm really hesitant to remove the crc32c sanity check, > > mainly because we've just been through a XFS corruption drill where > > one in 10^6 crc calculations would end up wrong because of a bug in > > a compiler. > > > > Can we "auto detect" cross compilation in the makefile and avoid the > > check only in that situation? configure options are really only a > > last resort... > > That sounds like the right path to me. So for 2) the plan is disable if cross-compiling, run unconditionally otherwise and no way to overwrite at configure time. As for 3) is there a point in having BUILD_CFLAGS introduced? > > Or cross-compile it but don't run it, and let package managers run > it at install time? ;) Of course I can implement it but I doubt we would see many packagers go that length. :) Cheers Ralph > > >> 4) sys/ustat.h is missing in musl. > > > > Yup, been reported before. I'm about to commit a fix for that, > > mainly because certain new arches don't even implement the ustat > > system call, and glibc completely fucks up the handling of that. > > i.e. programs that call ustat don't fail at build time, the syscall > > is stubbed to print "not supported, will fail" at runtime. Hence > > nobody noticed that the xfsprogs code calling ustat was actually > > broken until a week ago... > > Partly because we only checked for success, not failure, but nobody > rationally expected -ENOSYS any more than they expected the > Spanish Inquisition... > > -Eric > > > Cheers, > > > > Dave. > > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
