From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4129 invoked by alias); 11 Sep 2016 19:23:58 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39282 Received: (qmail 16987 invoked from network); 11 Sep 2016 19:23:58 -0000 X-Qmail-Scanner-Diagnostics: from mx.spodhuis.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(94.142.241.89):SA:0(-1.3/5.0):. Processed in 0.794628 secs); 11 Sep 2016 19:23:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=RP_MATCHES_RCVD,SPF_PASS, T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: zsh-workers+phil.pennock@spodhuis.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at spodhuis.org designates 94.142.241.89 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201608; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date; bh=hlqSaEkO1BsHYGvBtRgu9EJAwYJS9myf1nA63MS8Je4=; b=az2Ur3/1EJ58vPUCiwDCS4/CTe sKGMgzA80MPn63jKuPvCefYKgWmrCAiw03+smD8UStticNWrcX/VnitIQ5gfaGh2260RqChC56A7l 3X90sQMOmWWpGikdJacLEavKJQmeogdw9jvkZfqjFY1H5XGGHP5mvIFjIfR5735XFjOJkBO+b/hvR 8ZgKGR/tm4S7nhtMWiwEdKQ68Icn; Date: Sun, 11 Sep 2016 19:23:51 +0000 From: Phil Pennock To: zsh-workers@zsh.org Subject: Re: zsh/re2 : avoid until further notice Message-ID: <20160911192351.GA28725@tower.spodhuis.org> Mail-Followup-To: zsh-workers@zsh.org References: <20160908041556.GA8401@breadbox.private.spodhuis.org> <20160908144203.GA28545@fujitsu.shahaf.local2> <20160908204737.GA12164@breadbox.private.spodhuis.org> <20160908211643.GA4432@fujitsu.shahaf.local2> <20160909005557.GB12371@breadbox.private.spodhuis.org> <20160909045739.GA6623@fujitsu.shahaf.local2> <20160910010456.GA85981@tower.spodhuis.org> <20160910190924.GB4045@fujitsu.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160910190924.GB4045@fujitsu.shahaf.local2> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc [ returning to on-list with Daniel's permission; being a little repetitive with my answer to provide context for others ] On 2016-09-10 at 19:09 +0000, Daniel Shahaf wrote: > Phil Pennock wrote on Sat, Sep 10, 2016 at 01:04:56 +0000: > > On 2016-09-09 at 04:57 +0000, Daniel Shahaf wrote: > > > I don't follow the bit about "require setting a var". When the test > > > program crashes, AC_TRY_RUN evaluates its third parameter; when > > > cross-compiling, it evaluates the fourth. The first three actual > > > parameters seem fine to me. The fourth as written makes --with-re2 and > > > cross-builds mutually exclusive. > > > > In my testing (autoconf 2.69) I initially had: > > PROG =yes =no =unknown > > That's exactly what I would expect the result of the test to be. > > > and the =unknown for cross-compiling meant that when the build crashed, > > autoconf declared the status 'unknown' and continued. > > > > What do you mean, "when the build crashed"? When cross-compiling, > AC_TRY_RUN does not attempt to run the program it compiles and links. > If you mean, "when the test program would crash if run in the target > hardware", then I think there ought to be a way to enable re2 even for > cross-compiling. It could be, for example: At no point have I tried this with cross-compiling. I will also state up-front that I don't know autotools very well. If the cre2 shim library, which provides the C-language bindings to the re2 C++ library, is built with a different C++ compiler to that used for re2 then various weird failures happen at runtime. I have not been able to get to a simple case which will "exit false" on failure, reliably. The test program in the `AC_TRY_RUN` is as likely to segfault as to fail exiting cleanly. In my environment, 64-bit Intel, MacOS 10.10.5, re2 built with clang++ and cre2 built with either clang++ or g++-6, I tested this test-program with cre2 built with both compilers, to confirm that it seems to reliably detect in my environment when the environment is bad. With the AC_TRY_RUN(PROG,=yes,=no,=unknown), when the program crashed, the `./configure` run reported the status of that test as "unknown" and continued on. Yes, this was building locally, no cross-compiling. Changing the last parameter of the AC_TRY_RUN to be =no instead of =unknown resulted in the generated configure script correctly aborting. autoconf 2.69. This is not my reading of the documented behaviour of autotools, and I don't think it's your reading either. I am not asserting anything about how cross-compilation should work; for myself, =unknown and proceed-without-the-safety-check seemed a reasonable approach, which is why I tried it first and discovered that the non-cross-compiling build was affected by that fourth parameter. I don't know how to deal with this, other than if someone else can reproduce both the working and crashing scenarios and suggest a better test. In practice, the patch as included in zsh-workers 39249 works for me. > if test=unknown enableval=yes: issue a warning and go through with the build > if test=unknown enableval=no: build without re2 > > Or: > > if test=unknown enableval=force: go through with the build > if test=unknown enableval=yes: abort the build, instructing user to retry with --enable-re2=force > if test=unknown enableval=no: build without re2 > > (These examples are incomplete: they don't cover the non-cross case nor > the "neither --enable-re2 nor --disable-re2 passed" case.) > > (In light of your later remarks: feel free to CC the list upon reply.) At this point, the test is only run if `--enable-re2` is passed; the feature is hard-guarded by that flag. Also, I don't know if any of the ac logic should be in aclocal.m4, aczsh.m4, should stay in configure.ac or something else, and how this should be decided. If anyone has tried the zsh-workers 39249 patch, success/failure reports even on the basic functionality would be nice. :) Thanks, -Phil