bugGNU Octave - Bugs: bug #55613, Build failure with bison 3.3.1

 
 

bug #55613: Build failure with bison 3.3.1

Submitter:  Andrew Janke <apjanke>
Submitted:  Thu 31 Jan 2019 08:06:05 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.0.90 Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Feb 2019 10:29:47 PM UTC, comment #13: 

In case anyone needs it, attached here is a version of the patch ported to Octave 4.4.1. There is one more bison feature test in Octave 4.4.1 that was removed in Octave 5, so the patch is necessarily slightly different.

(file #46377)

Mike Miller <mtmiller>
Group Member
Mon 04 Feb 2019 07:00:56 AM UTC, comment #12: 
Mike Miller <mtmiller>
Group Member
Sat 02 Feb 2019 07:34:29 PM UTC, comment #11: 

I think you should commit any code you want before Sunday (2/3).  I'm going to ask jwe to make an RC2 candidate.

Rik <rik5>
Group administrator
Fri 01 Feb 2019 07:28:14 PM UTC, comment #10: 

Okay, then this sounds like a good change to make.

Rik <rik5>
Group administrator
Fri 01 Feb 2019 06:45:47 PM UTC, comment #9: 

Yes, we require bison 3.0 or newer, and we do still look at stderr even with the patch I have worked up, I did not need to drop that as I originally thought. Basically, nothing has changed in what we check for or what we require, the only change is adding a new option to the bison command line to silence the new warnings.

Mike Miller <mtmiller>
Group Member
Fri 01 Feb 2019 06:26:10 PM UTC, comment #8: 

Just checking, do we require Bison versus, say, yacc?  One reason to look at the stderr output in configure would be to see if someone had set up their environment variables so that yacc was actually being used.  It would fail on things like api.prefix which would then indicate that we didn't have a reliable parser generator installed.

Rik <rik5>
Group administrator
Fri 01 Feb 2019 04:25:30 PM UTC, comment #7: 

Right, this change doesn't alter the requirements of bison that we support at all. To be clear, Octave currently requires bison 3.0 or newer to generate the parser sources. This is a new requirement since 4.4, but was done about 6 months ago (https://hg.savannah.gnu.org/hgweb/octave/rev/e1c3d1c6e896). If a user tries to build with any bison 2.x, configure will warn that it found bison but it does not support the required syntax. This change simply adds the -Wno-yacc option to bison's command line, which is supported by all versions of bison that we already care about, and which fixes the bug here.

My earlier comment #3 about dropping the feature test entirely was when I forgot or didn't remember we had already made the change 6 months ago to require the new syntax.

Mike Miller <mtmiller>
Group Member
Fri 01 Feb 2019 10:55:21 AM UTC, comment #6: 

Sounds good to me.

One more data point: macOS is stuck on the old bison 2.3 (I think due to Apple's licensing preferences), but bison 3.3 is readily available via Homebrew, so I don't think that's a reason to keep support for the old 2.x series. You already have to install the new Homebrewed bison to get Octave to build correctly on macOS, so dropping support for 2.x won't introduce any new requirements.

Andrew Janke <apjanke>
Fri 01 Feb 2019 07:05:35 AM UTC, comment #5: 

I'm attaching the change I want to make on the stable branch, please comment if anyone has any objections. I've tested this with bison 3.2.4 and 3.3.1, both work for me, and I believe this change is both safe and the most appropriate solution.

Rationale - I did a bit more research into the recent change and the relationship between autoconf and bison. The bison 3.0 release notes specifically mention that a future version of autoconf will stop calling bison with the "-y" option. Until then, for all current versions of autoconf, users should call bison with "-Wno-yacc" added to AM_YFLAGS to silence warnings when using bison-specific directives. This option is safe for any version of bison 2.5 and newer.

Version 3.0 is also the first version to support the current "%define api.prefix {FOO}" syntax that Octave tests for and requires.

GNU bison 2.5 was released May 2011.

GNU bison 3.0 was released July 2013.

All supported versions of Debian and Ubuntu, even the old LTS versions (from 2014-2015), have bison 3.0 or newer.

CentOS 7 has bison 3.0.4, CentOS 6 has bison 2.4.1.

(file #46152)

Mike Miller <mtmiller>
Group Member
Thu 31 Jan 2019 07:46:26 PM UTC, comment #4: 

Bison 3.0 release date was Sept. 2015.  That probably means there are some really long-term releases that are still running versions less than 3.0, but everybody else should be fine.

There is an explicit workaround in the release notes for Bison 3.3


*** More POSIX Yacc compatibility warnings

  More Bison specific directives are now reported with -y or -Wyacc.  This
  change was ready since the release of Bison 3.0 in September 2015.  It was
  delayed because Autoconf used to define YACC as `bison -y`, which resulted
  in numerous warnings for Bison users that use the GNU Build System.

  If you still experience that problem, either redefine YACC as `bison -o
  y.tab.c`, or pass -Wno-yacc to Bison.



Rik <rik5>
Group administrator
Thu 31 Jan 2019 07:40:56 PM UTC, comment #3: 

My recommendation would be to drop the check for empty stderr on the stable branch to allow the current configure script to work with bison 3.3. I can test that a little later.

On the default branch I think we can drop the entire feature test for different bison source directives. We've talked about doing this before, and I think it's time. I believe bison 3.0 and later all support the new syntax "%define api.prefix {name}", so that should just be the only one we support now. The configure script can either drop the feature test completely or can run a simpler test to make sure that syntax is supported.

Mike Miller <mtmiller>
Group Member
Thu 31 Jan 2019 07:25:29 PM UTC, comment #2: 

Here is the new behavior from bison 3.3.1:


$ cat conftest.yy
%define api.prefix {foo_}
%start input
%%
input:;
%%
$ bison -y conftest.yy
conftest.yy:1.1-7: warning: POSIX Yacc does not support %define [-Wyacc]
 %define api.prefix {foo_}
 ^~~~~~~


The '-y' option is added automatically by autoconf's support for bison/yacc to make bison behave like POSIX yacc. The warning is only emitted when the '-y' option is present, and only with bison version 3.3 or later.

Octave's configure script captures both stdout and stderr and expects them to be empty to test for success. This warning is interpreted as a failure and so configure thinks that bison doesn't work with any of the known formats.

In the meantime, autoconf has been changed to drop the '-y' option on bison (https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=42761668c0300afa7f8bf5ba736458a818cd5d15), but that version of autoconf has not been released yet.

Mike Miller <mtmiller>
Group Member
Thu 31 Jan 2019 05:45:50 PM UTC, comment #1: 

The release announcement for bison 3.3 is here: https://lists.gnu.org/archive/html/info-gnu/2019-01/msg00016.html.

It mentions that api.prefix { PREFIX } is now the recommended style.  Octave checks for which style to use in a configure m4 macro in m4/acinclude.m4.  See


 AC_DEFUN([OCTAVE_PROG_BISON], [


So there is some reason why the configure test is failing.  Can you upload the file config.log after a configure which fails to locate bison?  That will have the actual results of each configure test that failed.

Rik <rik5>
Group administrator
Thu 31 Jan 2019 08:06:05 AM UTC, original submission:  

I recently upgraded from bison 3.2.4 to bison 3.3.1 and the Octave build from Hg (both stable and default) started failing.

Warnings in configure output indicate it's not recognizing the new bison:


checking for bison... bison -y
checking syntax of bison api.prefix (or name-prefix) declaration...
configure: WARNING:

I wasn't able to find a suitable style for declaring the api prefix
in a bison input file so I'm disabling bison.  We expect bison to
understand the '%define api.prefix { PREFIX }' syntax.

configure: WARNING:

I didn't find bison, or the version of bison that I found does not
support all the features that are required, but it's only a problem
if you need to reconstruct parse.cc, which is the case if you're
building from VCS sources.


Full build logs: https://gist.github.com/2664193746f65bbcc9b533cb7a3b4f53

Downgrading to bison 3.2.4 fixed the build.

Andrew Janke <apjanke>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46377:  bison-3.3.patch added by mtmiller (2KiB - text/x-patch)
file #46152:  bug55613.patch added by mtmiller (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-28 mtmiller Attached File- Added bison-3.3.patch, #46377
    2019-02-04 mtmiller StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2019-02-01 mtmiller Attached File- Added bug55613.patch, #46152
        StatusConfirmed Patch Submitted
    2019-01-31 mtmiller StatusNeed Info Confirmed
    2019-01-31 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code