From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 62AE23840C3B for ; Wed, 24 Jun 2020 02:38:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 62AE23840C3B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 05O2coNY025306 for ; Tue, 23 Jun 2020 19:38:50 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdQKuIDF; Tue Jun 23 19:38:42 2020 Subject: Re: zsh 5.8: configure fails only on 32bit To: cygwin-apps@cygwin.com References: <20200613.060556.1408580419815246249.yasu@utahime.org> <87lfkreckq.fsf@Otto.invalid> <20200624.082025.347584623379706940.yasu@utahime.org> From: Mark Geisert Message-ID: Date: Tue, 23 Jun 2020 19:38:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20200624.082025.347584623379706940.yasu@utahime.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:38:55 -0000 Yasuhiro KIMURA wrote: > Thank you for reply, and sorry for late response. > > From: ASSI > 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 > 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