Re: Errors when building from source

Akim Demaille <[email protected]>
Newsgroups gmane.comp.parsers.bison.general
Message-ID <[email protected]>
Hi Wouter!

> Le 26 déc. 2018 à 19:11, Wouter Beek <[email protected]> a écrit :
> 
> When I compile Flex prior to compiling Bison, I get the following error:
> 
>    $ make
>    Making all in src
>    make[1]: Entering directory '/home/wbeek/git/flex/src'
>    make  all-am
>    make[2]: Entering directory '/home/wbeek/git/flex/src'
>    /bin/bash ../build-aux/ylwrap parse.y y.tab.c parse.c y.tab.h
> `echo parse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e
> s/c++$/h++/ -e s/c$/h/` y.output parse.output -- ../build-aux/missing
> bison -y -d
>    /home/wbeek/git/flex/src/../build-aux/missing: 81:
> /home/wbeek/git/flex/src/../build-aux/missing: bison: not found
>    WARNING: 'bison' is missing on your system.
>             You should only need it if you modified a '.y' file.
>             You may want to install the GNU Bison package:
>             <http: www.gnu.org="" software="" bison="">
>    Makefile:1436: recipe for target 'parse.c' failed
>    make[2]: *** [parse.c] Error 127
>    make[2]: Leaving directory '/home/wbeek/git/flex/src'
>    Makefile:552: recipe for target 'all' failed
>    make[1]: *** [all] Error 2
>    make[1]: Leaving directory '/home/wbeek/git/flex/src'
>    Makefile:541: recipe for target 'all-recursive' failed
>    make: *** [all-recursive] Error 1

I didn't know Flex was using Bison.  AFAIR, years ago it was on
top of itself.  Did you start from a tarball of Flex?  It should
not require flex.  Likewise for Bison: you were starting from git,
not from a tarball; it is more demanding in this context.

> From the above I had concluded that I should first compile Bison and
> Flex later.

Can't you get Flex from your distro?


>  I've included the full log of Bison make at the end of
> this email.  I'm cloning Flex from https://github.com/westes/flex,
> which I assume is the official repo.

Yup.

> BTW, I also ran into the following error while running the `bootstrap'
> script in my local Bison directory for the first time:
> 
>    configure.ac:110: error: possibly undefined macro: AC_PROG_GNU_M4
>        If this token and others are legitimate, please use m4_pattern_allow.
>        See the Autoconf documentation.
>    autoreconf: /usr/bin/autoconf failed with exit status: 1
> 
> The link `m4/m4.m4' was not present in my local Bison directory.
> Following the discussion in
> https://lists.gnu.org/archive/html/bug-bison/2011-05/msg00012.html, I
> learned that running `git submodule update --init' prior to running
> `bootstrap' fixes this.

That's weird.  What "git status" noticing any difference?



>  Since this `git submodule' command step not
> normally be required, this may (or may not) be related to the issue I see
> when I run `make' later.
> 
> Finally, the `README' file mentions the `INSTALL' file, but in my local
> Bison directory this file was only generated later (by running
> `bootstrap' IIRC).

Yes.  INSTALL is not for people pulling the git repo, but running
the tarball.  README-hacking is for people working from the repo.


>  When this link is created, it seems to link to gnulib's
> `INSTALL' file.  IIUC there is not Bison-specific `INSTALL' file?

Nope, it's standard for GNU projects.


> checking for flex... no

Ok.


> $ make
> [...]
>  LEX      src/scan-code.c
>  LEX      src/scan-gram.c
>  LEX      src/scan-skel.c

I wonder what happened here.  Please, run "make V=1 src/scan-code.c".
It should show what command was actually run.

Cheers!
_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.