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