[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A bit more info about hanging bison on tru64 5.1b

From: Didier Godefroy
Subject: Re: A bit more info about hanging bison on tru64 5.1b
Date: Wed, 17 Jun 2009 23:49:00 +0200
User-agent: Microsoft-Entourage/

************ re-sending this message without the attachments, it came back
undelivered with them

on 6/17/09 5:12 PM, Akim Demaille at address@hidden uttered the

> Your mail was not unnoticed :)  Could you please try the following
> tarball?  Maybe the trouble is fixed --- it includes several various
> fixes.


> <URL:http://www.lrde.epita.fr/~akim/download/bison-2.4.334-4197.tar.gz>

Ok, it compiles fine as well, and gets stuck on the same things during the

To compile it, I throw those in the environment:

CFLAGS="-std -O4 -g3 -w"
CPPFLAGS="-I/usr/local/include -pthread"

And I used those following configure options:

configure \
--prefix=/usr/local \
--with-libiconv-prefix=/usr/local \
--with-libintl-prefix=/usr/local \

I'm attaching the output from configure and make, as well as the config.log.
The tests get stuck at the third test:

## ---------------------------------- ##
## GNU Bison 2.4.334-4197 test suite. ##
## ---------------------------------- ##

Input Processing.

  1: Invalid $n and @n                               ok
  2: Type Clashes                                    ok
  3: Unused values

The stuck test grabs almost 100% of a cpu and stays there forever.
Killing that hung process only gets it stuck again on the next one:

3: Unused values                                   FAILED (input.at:157)
4: Unused values before symbol declarations

And I know that if I continue killing the hung processes, there are many
tests after that that will succeed and some more will hang. I haven't tried
this again on the tarball, but that's what happened before.
I'm thinking that if whatever gets the first test stuck gets fixed, perhaps
the others won't get stuck either any more...???

Is there anything more I can supply to help track down this issue?

Also since I've also experienced similar problems with flex, I disabled it
and the previous bison that wouldn't work, so the configure won't detect any
flex and bison of course. I left the native lex but that may not help much.

The problem is bison is used by quite a few packages and some won't compile
properly without using it, so I'm unable to get several packages right now
for that reason. Fixing bison would really help...

Thanks much,

Didier Godefroy
Support anti-Spam legislation.
Join the fight http://www.cauce.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]