Control: tags -1 - moreinfo patch
Hi Bernhard,
Post by Bernhard SchmidtSorry 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.
Post by Bernhard SchmidtUpstream 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