public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Yasuhiro KIMURA <yasu@utahime.org>
To: cygwin-apps@cygwin.com
Subject: Re: zsh 5.8: configure fails only on 32bit
Date: Wed, 24 Jun 2020 08:20:25 +0900 (JST)	[thread overview]
Message-ID: <20200624.082025.347584623379706940.yasu@utahime.org> (raw)
In-Reply-To: <87lfkreckq.fsf@Otto.invalid> <23ce470a-9e82-612e-4208-d3e971080fa8@gmail.com>

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

  reply	other threads:[~2020-06-23 23:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 21:05 Yasuhiro KIMURA
2020-06-13  5:53 ` ASSI
2020-06-13  6:18 ` Marco Atzeri
2020-06-23 23:20   ` Yasuhiro KIMURA [this message]
2020-06-24  2:38     ` Mark Geisert
2020-06-24 23:28       ` Yasuhiro KIMURA
     [not found] <mailman.16.1593086404.1464.cygwin-apps@cygwin.com>
2020-06-25 21:09 ` Peter A. Castro
2020-06-26 22:56   ` Peter A. Castro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200624.082025.347584623379706940.yasu@utahime.org \
    --to=yasu@utahime.org \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).