Compilation error in lexer.cc

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build LLVM
2. Build GMP
3. Build Pure

What is the expected output? What do you see instead?
Expected compilation without errors. Instead of:
g++ -g -O2   -I/usr/local/include   -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -
D__STDC_CONSTANT_MACROS -I. -I. -c -o lexer.o lexer.cc
./lexer.cc: In function ‘int yy_get_next_buffer()’:
./lexer.cc:3868: error: invalid initialization of reference of type ‘int&’ 
from expression of type 
‘yy_size_t’
lexer.ll:67: error: in passing argument 3 of ‘void lex_input(const char*, 
char*, int&, int)’
make: *** [lexer.o] Error 1

What version of the product are you using? On what operating system?
Mac OS X 10.6.2 with Pure 0.39, LLVM 2.6 and GMP 4.3.1
Compiler: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) 
(dot 1)
Part of XCode Version 3.2.1 (1613)
bison (GNU Bison) 2.3

Please provide any additional information below.

LLVM Config.log:
./configure --enable-optimized --disable-assertions --disable-expensive-checks 
--enable-
targets=host-only

GMP config.log:
./configure
(make check succeeded)

Pure config log:
./configure

Note: Possibility that it is an error on my part as the process is manual. 
Thanks for relaxing the 
license terms which is why I try pure again.

Original issue reported on code.google.com by autoteli...@gmail.com on 20 Dec 2009 at 9:12

[GoogleCodeExporter]

That's apparently an incompatibility of your flex version. Which version did 
you use?

Original comment by aggraef@gmail.com on 21 Dec 2009 at 8:51

[GoogleCodeExporter]

The standard flex 2.5.35 in SnowLeopard btw. happened with make -B.

Also tried just 'make' it gives incompatible architecture errrors in linking 
pure and llvm. I followed the 
instructions in the INSTALL point by point. Perhaps 64-bit / 32-bit 
incompatibility in the compilations?
I did not have these issues with Pure 0.25 but that was with the older llvm and 
Mac OS X 10.5 (i.e. not 64-bit).

Also tried the MacPorts version, it gives Segmentation Fault on any use of map 
and also fails the eye example 
in the manual.

Original comment by autoteli...@gmail.com on 22 Dec 2009 at 9:01

[GoogleCodeExporter]

About the flex problem: 2.5.35 is what I have here on Linux, too, but it 
doesn't have
this problem. Looks like your version uses a slightly different (and 
incompatible)
lexer skeleton. I suggest to either use the lexer.cc that's provided in the 
release
tarball (i.e., 'make' instead of 'make -B', as you already did), or you'll have 
to
change the lex_input function in lexer.ll so that it takes a size_t& as the 
third
parameter instead of int&.

About the linkage errors: That's a known LLVM issue (in fact, the MacPorts build
originally had the same problem). The solution is to add a slew of options to
configure. See:

http://groups.google.com/group/pure-lang/browse_thread/thread/b96c1f2c929d2c65
http://trac.macports.org/ticket/22578
http://llvm.org/bugs/show_bug.cgi?id=5012

(Judging from the LLVM port file in MacPorts, just specifying the proper --build
option when configuring LLVM might be enough. In any case, the latest version 
of the
MacPorts port should work fine now.)

About the segmentation faults on 64 bit/Snow Leopard: That's a known issue, too.
Apparently the LLVM JIT is broken on OSX 2.6. See:

http://groups.google.com/group/pure-lang/browse_thread/thread/325daccbd9439a00

(But this is really a separate issue, so I'd appreciate it if you could file a 
new
problem report for it.)

At present, the only known workaround for the JIT problems is to build Pure as 
a 32
bit application on OSX 2.6. You should ask Ryan Schmidt (the maintainer of the
MacPorts Pure port) on the Pure mailing list about that; he's tried it and says 
that
it works. There's also the possibility that this might have been fixed in LLVM 
svn,
see the above mailing list thread for details. I can't test any of that myself, 
as I
don't have access to an Intel/OSX machine.

Original comment by aggraef@gmail.com on 22 Dec 2009 at 12:54

[GoogleCodeExporter]

Yes, I can confirm the flex problem. Apparently, Apple's flex incorporates a
post-2.5.35 upstream patch of the scanner skeleton that changes yyleng and 
yy_n_chars
from int to yy_size_t (which is typedefed to size_t, which of course is 64 bit 
on a
64 bit system). See:

http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.212&r2=2.213

I'll install the cvs version of flex to reproduce the problem, so that I can 
design a
workaround. This will go into Pure 0.40.

Original comment by aggraef@gmail.com on 22 Dec 2009 at 1:09

• Changed state: Started

[GoogleCodeExporter]

The flex issue is fixed in r2838. Thanks for reporting.

Original comment by aggraef@gmail.com on 22 Dec 2009 at 1:48

• Changed state: Fixed