Re: libidn malloca compile fails GNULIBHEADERS_OVERRIDE_WINT_T not set

[Brian Inglis]

On 2021-07-27 02:52, Simon Josefsson wrote:
> Brian Inglis writes:
> > Aargh!
> > It's back and I can now see lib/wint_t.m4 downgraded to serial 5 while
> > gl/wint_t.m4 retained as serial 11!
>
> Yes, this happens if you (directly or indirectly) run 'autopoint
> --force' in the extracted tarball directory.

> > Could you please check your current build release of
> > gettext-dev/devel, see where it's sourced from, where it's built, and
> > if it's got any local patches for wint_t.m4?

> We get wint_t.m4 from gnulib, and the other gnulib m4 macros (stdint.m4)
> rely on getting the right wint_t.m4.  Gettext's autopoint pulls in an
> older wint_t.m4 for you.
>
> I'm not sure what the best upstream approach to this problem is.
> Traditionally, users just unpack the tarball and build the package.
> Nowadays, people often run autoreconf etc to make sure they are
> re-building from source code, and that makes some sense.  The problem is
> that there is no stable way to re-bootstrap projects from a tarball
> release generically.  Running 'autoreconf' was not intended to serve
> that purpose, I think.

Managed to get gettext current built and packaged so libidn build 
problem now resolved and should stay that way.
Both Cygwin 64 and 32 bit libidn builds okay.
Now working on libidn Mingw x64 and x86 cross-builds which may have 
their own issues, but gettext current Mingw x64 and x86 were also built 
and packaged so that should be no issue.
Thanks very much for all your help. Cheers ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]