Yasuhiro KIMURA wrote:
Thank you for reply, and sorry for late response.
From: ASSI <stromeko-i47jitek...@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+a...@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...
..mark
