Control: tags -1 - moreinfo patch Hi Bernhard,
On Tue, Nov 05, 2024 at 10:59:06PM +0100, Bernhard Schmidt wrote: > Sorry for letting this slide. Unfortunately your patch does not apply > to the current 1.7.5-1 upload I just made and I lack the crossbuild > knowledge to properly fix it up (it would be very much trial and error). Thank you for following up. I fear that things got more difficult now. In essence, any time you use AC_RUN_IFELSE without a fourth argument, cross compilation fails. The fourth argument is a guess that is applied for cross compilation and means the check is skipped - which most often is not what you want, so avoiding AC_RUN_IFELSE as much as possible is what we want. There are now four AC_RUN_IFELSE: https://github.com/phaag/nfdump/blob/master/configure.ac#L220 is new and used for checking the rrd version. For doing so, the library is loaded and iterrogated and that's something that doesn't work for cross compilation in any way. Would it be an option to use PKG_CHECK_MODULES([RRD],[librrd >= 1.0],[ dnl rrd has been found via pkg-config. Trust its version. LDFLAGS="${LDFLAG} ${RRD_LIBS}" CFLAGS="${CFLAGS} ${RRD_CFLAGS}" ],[ dnl no pkg-config. Check as before using AC_CHECK_HEADER and dnl AC_RUN_IFELSE from lines 204 to 242. ]) This will make the earlier checking code be unused in the vast majority of cases (where librrd is equipped with a .pc file) while still keeping it as a fallback for legacy installations. Is that acceptable? https://github.com/phaag/nfdump/blob/master/configure.ac#L290 and https://github.com/phaag/nfdump/blob/master/configure.ac#L336 do not benefit from running. They can be demoted to AC_COMPILE_IFELSE or AC_RUN_IFELSE (though no symbols are being used, so linking will not actually test anything) without loosing precision as in my earlier patch. https://github.com/phaag/nfdump/blob/master/configure.ac#L624 is where printf is being checked for %z. This is one of those cases where you really have to use AC_RUN_IFELSE and there is no sensible way around. What cross builders tend to do here is externally providing the result and the mechanism for that is wrapping the check in AC_CACHE_CHECK. Note that this check pessimistically adds a fourth argument indicating that whenever we are cross building, we assume %z to not work. So this doesn't actually break cross compilation, but produces suboptimal builds. I don't think there is much magic to cross compilation here: * If you use PKG_CHECK_MODULES and your native configure log indicates that it skips the fallback check, it'll work for cross. (case 1) * If you don't use AC_RUN_IFELSE and it works natively, it'll work for cross. (cases 2 and 3) * If you provide the cache variable via the environment and AC_CACHE_CHECK says "cached", it'll work for cross. (case 4) * If you want to test cross compilation, add --host=somearch to your sbuild invocation or --host-arch=somearch to your pbuilder invocation. I'm declining to spell out this patch for now, because much of it would be re-indenting the first and fourth check. It also requires choosing a sensible cache variable name for your case (e.g. ac_cv_printf_format_z_works). The details of much of this depend on particular upstream preferences that tend to be non-uniform across autotools users. > Upstream is very responsive so I would suggest opening a pull request at > https://github.com/phaag/nfdump/pulls . If you don't want to but can > provide an updated patch I can do this for you. Can I ask you to take another stab at this? I tried github a couple of times, but I have not yet found a good way of interacting with it: * Its notification mails lack context. * Its notification mails are not properly threaded. * When the PR is done, I have a fork in my namespace that I have to remember to clean up. It tends to work better if you continuously work on the same projects, but if you drive by contribute to thousands of projects, github simply doesn't scale. Helmut
