More configure problems

When I ran configure after updating, I get various errors. First:

% ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i386-unknown-freebsd5.2.1
checking host system type... i386-unknown-freebsd5.2.1
checking target system type... i386-unknown-freebsd5.2.1
test: Unknown: bad number

And finally:

config.status: creating Makefile.config
config.status: creating include/Support/DataTypes.h
config.status: creating include/Support/ThreadSupport.h
config.status: creating include/Support/hash_map
config.status: creating include/Support/hash_set
config.status: creating include/Support/iterator
config.status: creating include/Config/config.h
config.status: linking ../lib/System/Unknown to lib/System/platform
config.status: error: ../lib/System/Unknown: file not found

I hacked up the configure script to treat freebsd the same as linux and
started the build. We'll see if the two are similar enough for it to
work. The change caused the first error to become:

test: Linux: bad number

> When I ran configure after updating, I get various errors. First:
>
> % ../configure --enable-jit --with-llvmgccdir=/home/llvm/cfrontend/x86/llvm-gcc
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... i386-unknown-freebsd5.2.1
> checking host system type... i386-unknown-freebsd5.2.1
> checking target system type... i386-unknown-freebsd5.2.1
> test: Unknown: bad number
>
> And finally:
>
> config.status: creating Makefile.config
> config.status: creating include/Support/DataTypes.h
> config.status: creating include/Support/ThreadSupport.h
> config.status: creating include/Support/hash_map
> config.status: creating include/Support/hash_set
> config.status: creating include/Support/iterator
> config.status: creating include/Config/config.h
> config.status: linking ../lib/System/Unknown to lib/System/platform
> config.status: error: ../lib/System/Unknown: file not found

I hacked up the configure script to treat freebsd the same as linux and
started the build. We'll see if the two are similar enough for it to
work. The change caused the first error to become:

test: Linux: bad number

This isn't my day...

gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen'
Bisoning FileParser.y
Flexing /usr/home/llvm/obj/../utils/TableGen/FileLexer.l
gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen'
gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen'
Compiling AsmWriterEmitter.cpp
Compiling CodeEmitterGen.cpp
Compiling CodeGenTarget.cpp
Compiling FileLexer.cpp
Compiling FileParser.cpp
FileParser.tab.c: In function `int Fileparse()':
FileParser.tab.c:2043: error: syntax error before `goto'

The offending lines bison generated are:

/*----------------------------------------------------.

yyerrlab1 -- error raised explicitly by an action. |

`----------------------------------------------------*/
yyerrlab1:

  /* Suppress GCC warning that yyerrlab1 is unused when no action
     invokes YYERROR. */
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
  __attribute__ ((__unused__))
#endif

  goto yyerrlab2; <== line 2043

I'm using bison 1.875. But it worked the last time, so I don't know why
it doesn't work now. Deleting the __attribute__ clause fixes it.

Ugh. Sorry, my bad.

I used "test" incorrectly .. coding in too much of a hurry. Anyway,
its fixed now. This patch also treats freebsd the same as Linux .. for
now.

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040830/017648.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040830/017649.html

Reid

That's the symptom of writing:

  if test X -eq Y

instead of

  if test X = Y

when X and Y are not numeric.

This is fixed in the latest patch I sent earlier.

Reid.

This has come up before. Its a bison bug. You'll need to try an older
version. I use 1.35 and all works fine.

LLVM Bug: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=302
Bison Bug:
http://mail.gnu.org/archive/html/bug-bison/2004-01/msg00011.html

Reid.

I want to play around with the GLR support in the recent bison, so I
simply fixed the skeleton.

What do you mean by "fixed the skeleton"? Hacked the output of bison so
that it compiled?

I suppose what we ought to do is have a bison post-processor that scans
the bison output for this problem and corrects it. Could you do that?

Reid.

More like I hacked bison itself. The skeleton used by bison to generate
the parser is a separate file from the binary itself. On my machine the
skeleton is /usr/local/share/bison/yacc.c.