Re: libidn malloca compile fails GNULIBHEADERS_OVERRIDE_WINT_T not set

[Simon Josefsson]

Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:

> 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 ;^>

Great!  Are these published anywhere?  Would be useful to know about, in
case anyone asks about Cygwin/MinGW.

Btw, MinGW builds are tested as part of GitLab CI/CD of libidn:
https://gitlab.com/libidn/libidn/-/pipelines/341319083

/Simon

signature.asc
Description: PGP signature