zsh 5.8: configure fails only on 32bit

Mark Geisert mark@maxrnd.com
Wed Jun 24 02:38:42 GMT 2020

Yasuhiro KIMURA wrote:
> Thank you for reply, and sorry for late response.
> From: ASSI <Stromeko-i47jiTeKxPI@public.gmane.org>
> 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-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org>
> 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.

Not sure if your end result will be a patch to the Cygwin zsh package or an ITA 
of same.  In either case it seems like the Cygwin zsh maintainer (Peter A. 
Castro) ought to be brought into this conversation...


More information about the Cygwin-apps mailing list