[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn malloca compile fails GNULIBHEADERS_OVERRIDE_WINT_T not set

From: Brian Inglis
Subject: Re: libidn malloca compile fails GNULIBHEADERS_OVERRIDE_WINT_T not set
Date: Mon, 26 Jul 2021 15:59:06 -0600
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

On 2021-07-26 12:17, Simon Josefsson wrote:
Brian Inglis writes:
Under Cygwin 64 and 32, libidn malloca compile fails because gl/stdint.h
is generated (for some reason, possibly because gnulib is yet to be or
may not be ported to Cygwin, as Cygwin uses newlib rather than glibc,
and is not Linux) with no value set for GNULIBHEADERS_OVERRIDE_WINT_T
in #if, as no tests are configured to set the value under Cygwin:
please see attached log for details.

Thanks for the report.  This can happen if an old wint_t.m4 is used.
Did you build directly from the tarball?  Did you run any of autoreconf,
autopoint or libtoolize?  Make sure wint_t.m4 in your build tree is
'serial 11'.  See some comments in bootstrap.conf..

Yes - built using cygport CygWin ports utility (based on Gentoo portage with bits of RPM spec added, as RedHat volunteers and Fedora users are core distro and package maintainers) using bash script variable definitions and high level function class overrides, from GNU mirrors tarball, running autoreconf, autoconf, automake. As libidn uses gettext and Cygwin uses DLLs not .so shared libs, autopoint, libtoolize, autoconf, autoheader, and automake are run by autoreconf.

I don't have access to a cygwin machine so I can't easily reproduce this
myself.  One thing you can check is the ./configure output: does it
contain 'whether wint_t is large enough'?  Otherwise something rebuilt
the ./configure script for you and used the wrong wint_t.m4 file.

As far as I can find, the only wint_t.m4 is in your gl/m4 directory.
But from the config log, it does not appear to be invoked, as there is no "large enough" test.

Thinking there might be issues from the previous build, I blew that whole build tree from yesterday for 1.38 away and reran, and now the large enough test and result appears!?

So something must have glitched somewhere during an earlier attempt, causing a later attempt to produce that error, although exactly the same thing happened in my earlier attempts to build current versions!?

Thanks very much for all your help. Sorry if I wasted your time. I'll have to be more careful with these builds, to ensure if anything goes wrong, everything gets wiped before retries.

However, success means I can at last move on to doing cross-builds of mingw64 64 and 32 bit releases, and if all succeeds, adopt all Cygwin libidn packages, which were orphaned when the previous maintainer got overloaded after the IBM acquisition of RedHat, and update all releases to current from 1.33!

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]