nfdump fails to cross build from source, because its configure.ac has
gained a couple of AC_RUN_IFELSE. A number of them are used in a way
where running the compiled program doesn't gain any actual information
beyond just compiling. Hence those can be easily downgraded to
AC_COMPILE_IFELSE. The one AC_RUN_IFELSE about %z has a cross
compilation default and is only relevant for testing anyway. So with the
attached patch, nfdump cross builds again. Please consider applying it.

Helmut

On 06/02/24 07:06 PM, Helmut Grohne wrote:

Dear Helmut,

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).

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.

Bernhard

Hi Bernhard,
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.

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

We believe that the bug you reported is fixed in the latest version of
nfdump, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1063383@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard Schmidt <berni@debian.org> (supplier of updated nfdump package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 28 Aug 2025 23:35:58 +0200
Source: nfdump
Architecture: source
Version: 1.7.6-1
Distribution: unstable
Urgency: medium
Maintainer: Erik Wenzel <erik@debian.org>
Changed-By: Bernhard Schmidt <berni@debian.org>
Closes: 1063383
Changes:
 nfdump (1.7.6-1) unstable; urgency=medium
 .
   * [ce499588] New upstream version 1.7.6 (Closes: #1063383)
   * [8e1f5019] Remove patches applied upstream
Checksums-Sha1:
 ecd9fdfc85880367d4323ae1f379ad24d18c0513 2038 nfdump_1.7.6-1.dsc
 e2615dd08e0d6ee427e2b88272716633e9e6b7d0 844753 nfdump_1.7.6.orig.tar.gz
 b660d93ea49455f7538dbdbadfedeaa4115fd5d9 11592 nfdump_1.7.6-1.debian.tar.xz
 afb9464fe9ac27011d4bc72ba56175551a264102 8048 nfdump_1.7.6-1_amd64.buildinfo
Checksums-Sha256:
 9fdbb17dbb973f47d2382fb62f54f1c97bc642a1c8d23356f29db502b0e4c999 2038 nfdump_1.7.6-1.dsc
 2d25220d7a48f57ba65f228fb5d2eb4d2a0ab2b352a037ed6249b39cf68c1b9a 844753 nfdump_1.7.6.orig.tar.gz
 cbcc6238cfa73d9100761c7b6687968aa74a59fd2f9f5fc394fa6de7c7c25fd0 11592 nfdump_1.7.6-1.debian.tar.xz
 2c7db23d68034d4eef71413307fcef1a7ab871aa27eb8b7ad32aa96db2026f9c 8048 nfdump_1.7.6-1_amd64.buildinfo
Files:
 be4cd973cdc40f0b799cd55e280b5b96 2038 net optional nfdump_1.7.6-1.dsc
 0690b3f77c0b7fd22f5d4d6fbb0d4c72 844753 net optional nfdump_1.7.6.orig.tar.gz
 47de2ac02fc1ea648a32730d50809667 11592 net optional nfdump_1.7.6-1.debian.tar.xz
 72fedc626c4c46751903bdfbec10bcb7 8048 net optional nfdump_1.7.6-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEE1uAexRal3873GVbTd1B55bhQvJMFAmiw0DoRHGJlcm5pQGRl
Ymlhbi5vcmcACgkQd1B55bhQvJNrSw/8Dy5VkpRpqVF9jDWWq5apjBd5IjfsYuRK
HbYikBXxHNmCKG8dofISJ49XVXyrzFcky1VJ2Z+JgCtFM6/4Oe13Zc0kV1MeM+w9
tC+D6GiXzKSuaMTK0jKtrUxOa6LyXWhbCJv+0N1gjH2rBjq5ZkLJp4dIbMYqCKkN
eMw95zersv2ShP3QEP8hoOqwAjU49WwXxeQ7ioNVjlf1MWNwAu3MYPVIEb4agmEg
3Z986NllTw4lri77sq2IHyPLxKpQwxnlTU7oTj60xQORM4NMfKq9/2752w985ayl
5YYXnOD6Ewfgq3eOyX5esQMtGY2vWE3UUA8Elyn2PCAQfHvw/qJSDg5n2jFyKSe9
FdIPpefbFSUsb6n9JPJNETe/xEwvaPYhnA0DhzQwP+3XstnVOYnJLjoYHGzZ8XJy
R8GQ9hFCCTgPG7XgUT1UIIsZIekyIpe2lmTCWO9EsZL9L/eX+SzM3/b1IGbCu5Iu
oOzustldpoMMaA3J6wfUT3IOUN8DvNKtGj6g3G0cQs7h307AYDnDhmkKq1Vf+20d
Xk3VDTJULGVUq1I2XyPAgBCua/naimuMSP8nBlC9UBPOpYK3Hl7Fwo+V8uC3dHbv
Nemg7kUYGoT8w+3jtypIATmRIwLpPXWtLat2zeXYeXzygEN7g/hS1fBzsVq7dS5N
1LTIJQQFwhc=
=BLOu
-----END PGP SIGNATURE-----

Control: reopen -1
Control: found -1 nfdump/1.7.6-1
Control: tags -1 + fixed-upstream

I can see that the upstream MR is merged and checking the upstream git
head, I see no AC_RUN_IFELSE left, but what has been uploaded to Debian
still has AC_RUN_IFELSE. Not sure what went wrong here, but it is not
fixed.

Helmut