wget autoreconfigure problem

Hi all,

I'm running into a problem with wget and gettext. The problem is not caused by Buildroot, but it would be good to have a workaround. Also I would like some advice on which upstream to contact for a definitive fix.

The problem is triggered since commit 84bf8f04 (wget: fix build against uclibc snapshot), because that triggers an autoreconfigure by adding "WGET_AUTORECONF = YES" to "package/wget/wget.mk".

The build of wget fails with the following error message:

make[3]: Entering directory `/home/mth/gcw0/buildroot/output/build/wget-1.15/po'
*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 make[3]: *** [check-macro-version] Error 1

The wget-1.15 source from the tarball is designed to be used with gettext 0.17: the mentioned Makefile template "po/Makefile.in.in" defines "GETTEXT_MACRO_VERSION = 0.17". The configure macros in "m4/po.m4" are also from gettext 0.17.

What happens on the autoreconfigure though is that aclocal will start searching for m4 files and picks up "$(HOST_DIR)/usr/share/aclocal/po.m4", which is from gettext 0.18. Apparently gettext doesn't support mixing of versions and has sanity checks to prevent that, which is where the error message comes from.

For some reason this problem occurs on my machine, but doesn't occur for Paul Cercueil when building the same git revision. A possible explanation is that "package/wget/wget.mk" does not declare a dependency on gettext, so whether it will build with or without gettext support is just a matter of which package gets built first; I don't think that is a desirable situation.

When it comes to a solution, I don't really know where to start. I tried to disable scanning host directories for m4 files and while that fixes gettext, it breaks util-linux. So a quick hack is probably not the solution here.

I don't know how it is designed to work: apparently m4 files can either be included with the package or be searched for systemwide. But which is the primary file and which is the fallback? If the in-package file should take precedence, then aclocal should always take the in-package file if it exists. If the systemwide file should take precedence, then having hardcoded version dependencies like gettext does is invalid.

Does anyone here know how the aclocal m4 search is supposed to work? Since that would determine which upstream package should be approached for a fix.

Bye,
Maarten

Dear Maarten ter Huurne,

This problem has been fixed by
http://git.buildroot.net/buildroot/commit/package/wget?id=f8a2497287fa8fc0afa7698c30284a7674723aa2.

Can you confirm it also fixes the problem for you?

Best regards,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Paul Cercueil pointed me towards commit 1da2bb5e and 1b9bfce1 which fix the issue. We were using 2014.02 though, which predates those commits.

Bye,
Maarten