zsh 5.8: configure fails only on 32bit

Yasuhiro KIMURA yasu@utahime.org
Tue Jun 23 23:20:25 GMT 2020


Thank you for reply, and sorry for late response.

From: ASSI <Stromeko@nexgo.de>
Subject: Re: zsh 5.8: configure fails only on 32bit
Date: Sat, 13 Jun 2020 07:53:25 +0200

> To me that indicates either BLODA interference or that you run into some
> limit (e.g. on environment size or PATH length).
> 
> More generally I'd advise everyone to not build in your Windows user
> directory (which Windows specially "protects" in various ways) and never
> use any /cygdrive prefix while building packages (these are mounted with
> posix=0 mount option by default).  If you have the option, use a
> separate SSD for all of Cygwin and create a separate mount point for the
> build directory that mounts with "posix=1,binary".  I haven't sprung for
> full case sensitivity yet myself since that still entails mucking with
> the registry more than I want to, but I've run into problems with that
> once or twice (which I've worked around).  Install Cygwin into a
> directory two levels down the root (i.e D:\Freeware\Cygwin) in order to
> not get "special" treatment from Windows.  I have forgotten what the
> exact problem was, but putting the Cygwin install directory directly
> into the root triggered some BLODA several years ago.  Also if you use
> Cygwin for yourself on that same machine it is better to have a separate
> user account for building (I use a dedicated build machine).  Set
> CYGWIN_NOWINPATH=1 in the system or user environment options of Windows
> for the build user.  Be aware that some packages need to build or tested
> with admin rights enabled (that's a whole 'nother reason to not use your
> main account, as these days it shouldn't have admin rights at all),
> which I generally have since I build via ssh.  Once in a while you'll
> run into some test that fails until you aren't admin, in which case you
> can use cygdrop.  Lastly, once you need to build GUI applications you
> might want to be able to RDC into your build box, which means it should
> have at least the "Professional" variant of Windows installed.

I tried what you say with newly clean installed 64bit Windows 10 Pro
1909. But problem still happens.

From: Marco Atzeri via Cygwin-apps <cygwin-apps@cygwin.com>
Subject: Re: zsh 5.8: configure fails only on 32bit
Date: Sat, 13 Jun 2020 08:18:56 +0200

> what cygwin version and terminal are you using ?
> I saw a similar problem in the past
> 
> https://sourceware.org/pipermail/cygwin/2020-April/244363.html
> https://sourceware.org/pipermail/cygwin-apps/2020-May/040107.html
> 
> and it went away with a recent cygwin

yasu@rolling[1070]% cygcheck -c cygwin mintty
Cygwin Package Information
Package              Version        Status
cygwin               3.1.5-1        OK
mintty               3.2.0-1        OK
yasu@rolling[1071]%

And after number of trials and errors I add following definition of src_compile
function to zsh.cygport.

----------------------------------------------------------------------
src_compile() {
    cd ${S}
    cygautoreconf
    cd ${B}
    dash ${S}/configure --srcdir=${S}  --prefix=$(__host_prefix) --exec-prefix=$(__host_prefix) --localstatedir=$(__host_localstatedir) --sysconfdir=$(__host_sysconfdir)  --infodir=$(__host_prefix)/share/info --mandir=$(__host_prefix)/share/man -C --enable-function-subdirs --enable-gdbm --enable-multibyte --enable-pcre --enable-zsh-secure-free || error "configure failed"
    cygmake
}
----------------------------------------------------------------------

This is same as default definition except that dash is used to
interpret configure script. And with it build succeeded on 32bit
Cygwin console. So It seems I hit bug of bash that only happens under
very limited conditions.

And I'm wondering if I should investigate the problem further or
accept adding the function definition as a workaround.

---
Yasuhiro KIMURA


More information about the Cygwin-apps mailing list