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