Re: Bison 1.875 won't build on Tru64 4.0 Unix

[Paul Eggert]

Tony Leneis <address@hidden> writes:

> brahma:/home/tony/build/bison-1.875> CFLAGS='-std1 -fast -O4 -tune host -arch 
> host' ./configure

Why did you specify those optimization options?  Have they proved
reliable in the past for you, with other programs?  Does Bison still
dump core if you don't specify CFLAGS, or set CFLAGS='', before
invoking ./configure?  It is possible that there is a compiler bug
when optimization is turned up high on your host.


> config.status: creating Makefile
> ...
> brahma:/home/tony/build/bison-1.875> make
> There seems to be no Makefile in this directory.
> You must run ./configure before running `make'.
> make: *** [all] Error 1

When this occurs, is there indeed a file named "Makefile" in this
directory?  It appears that there is one, since /bin/make sees it.
If so, then the most likely problem is that your make (GNU Make 3.80)
is buggy on your platform.

GNU make first reads the file GNUmakefile, which has this code:

        have-Makefile := $(shell test -f Makefile && echo yes)

        # If the user runs GNU make but has not yet run ./configure,
        # give them a diagnostic.
        ifeq ($(have-Makefile),yes)

        include Makefile
        include $(srcdir)/Makefile.maint

        else

        all:
                @echo There seems to be no Makefile in this directory.
                @echo "You must run ./configure before running \`make'."
                @exit 1

        endif

One theory is that the "shell" builtin is broken on your platform,
so that it doesn't return "yes" even though the file Makefile exists.
You can test this theory by appending the following to GNUmakefile:

        test-have-Makefile:
                echo $(have-Makefile)

and then typing "make test-have-Makefile".  If the output is not
"yes", then your GNU Make installation is broken, either because GNU
Make itself is buggy, or because something else about your host isn't
working (perhaps the compiler?).

Even if your GNU make is broken, though, the Makefile generated by
"configure" should work with the system /bin/make.  And yet you report:

> brahma:/home/tony/build/bison-1.875> /bin/make
> No suffix list.
> make  all-recursive
> make: *** No rule to make target `all-recursive'.  Stop.
> *** Exit 2
> Stop.

This is strange, since the Makefile that you sent us had these lines:

> RECURSIVE_TARGETS = info-recursive dvi-recursive pdf-recursive \
>       ps-recursive install-info-recursive uninstall-info-recursive \
>       all-recursive install-data-recursive install-exec-recursive \
>       installdirs-recursive install-recursive uninstall-recursive \
>       check-recursive installcheck-recursive
> ...
> $(RECURSIVE_TARGETS):
>       @set fnord $$MAKEFLAGS; amf=$$2; \
>       ...

And this should define a rule to make the target `all-recursive'.  Can
you investigate why it didn't do that?  Perhaps your make has a
debugging option, and you can run something like "make -d
all-recursive" to see what's going on.


You write that many tests fail.  I don't see much of a pattern to the
core dumps.  But can you investigate the first one (test 4) to see why
it dumps core?  Quite possibly they all fail for the same reason.

To do this, you can run this command:

cd tests
./testsuite -v -d 4

When you get a core dump in a file "core", you can get a stack
backtrace with something like the following commands:

gdb .../src/bison core
where