Re: [pure-lang-users] Pure on Mac OS X

[Ryan S. <rya...@us...>]

On Apr 30, 2008, at 1:35 PM, Albert Graef wrote:
> Albert Graef wrote:
>> Ryan Schmidt wrote:
>>> I tried building on Mac OS X 10.4.11 PPC and got this:
>>>
>>> Command output: make: *** No rule to make target `/usr/local/ 
>>> include/
>>> llvm/DerivedTypes.h', needed by `expr.o'.  Stop.
>>
>> Hmm yes, the distributed Makefile shouldn't have all those LLVM
>> dependencies, I'll fix that.
>
> Fixed.
>
>>> interpreter.cc:1325: error: no match for 'operator!=' in 'it !=
>>> std::list<_Tp, _Alloc>::rend() [with _Tp = rule, _Alloc =
>>> std::allocator<rule>]()'
>>
>> I'll look at that tomorrow. I don't get that error here, maybe  
>> it's an
>> incompatibility in the STL.
>
> That's a bug in older GNU STL versions:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11729
>
> I changed the reverse_const_iterator there to an ordinary
> reverse_iterator, that should fix it. Ryan, can you please check that
> the trunk from SVN compiles now?

I tried compiling trunk at revision 10. With Mac OS X 10.4's flex  
2.5.4 and bison 1.28, if I do "make all" I get:


bison -v -o parser.cc parser.yy
parser.yy:7: unrecognized: %skeleton
parser.yy:7:    Skipping to next %
parser.yy:8: unrecognized: %require
parser.yy:8:    Skipping to next %
parser.yy:9: unrecognized: %defines
parser.yy:9:    Skipping to next %
parser.yy:34: unrecognized: %parse_param
parser.yy:34:    Skipping to next %
parser.yy:35: unrecognized: %lex_param
parser.yy:35:    Skipping to next %
parser.yy:38: unrecognized: %locations
parser.yy:38:    Skipping to next %
parser.yy:39: unrecognized: %initial_action
parser.yy:39:    Skipping to next %
parser.yy:50: unrecognized: %debug
parser.yy:50:    Skipping to next %
parser.yy:51: unrecognized: %error_verbose
parser.yy:51:    Skipping to next %
parser.yy:234: unrecognized: %destructor
parser.yy:234:    Skipping to next %
parser.yy:238: unrecognized: %destructor
parser.yy:238:    Skipping to next %
parser.yy:239: unrecognized: %printer
parser.yy:239:    Skipping to next %
parser.yy:242: unrecognized: %printer
parser.yy:242:    Skipping to next %
parser.yy:243: unrecognized: %printer
parser.yy:243:    Skipping to next %
parser.yy:244: unrecognized: %printer
parser.yy:244:    Skipping to next %
parser.yy:251: invalid input: %start
parser.yy:251: ill-formed rule: initial symbol not followed by colon
make: *** [parser.cc] Error 1


And if I do "make depend all" I get:


flex -o lexer.cc lexer.ll
flex: can't open lexer.cc
make: *** [lexer.cc] Error 1


Should I be running "make depend all" or "make all"?

If I install flex 2.5.35 with MacPorts then flex can run in "make  
depend all" but bison fails again as above.

I see you wrote in another thread on this list that bison 2.1a is now  
needed. Ok. Once I install bison 2.3 with MacPorts then that works  
too, but now it ends at:


flex -o lexer.cc lexer.ll
bison -v -o parser.cc parser.yy
makedepend -Y expr.cc expr.hh funcall.h interpreter.cc interpreter.hh  
lexer.ll matcher.cc matcher.hh parser.yy printer.cc printer.hh  
pure.cc runtime.cc runtime.h symtable.cc symtable.hh util.cc util.hh  
lexer.cc parser.cc parser.hh location.hh position.hh stack.hh 2> /dev/ 
null
g++ -g -Wall `llvm-config --cppflags`   -c -o expr.o expr.cc
g++ -g -Wall `llvm-config --cppflags`   -c -o interpreter.o  
interpreter.cc
interpreter.cc: In member function 'llvm::Value* interpreter::fbox 
(Env&, bool)':
interpreter.cc:3269: warning: control reaches end of non-void function
interpreter.cc: In member function 'llvm::Value* interpreter::fref 
(int32_t, uint8_t, bool)':
interpreter.cc:3494: warning: control reaches end of non-void function
g++ -g -Wall `llvm-config --cppflags`   -c -o matcher.o matcher.cc
g++ -g -Wall `llvm-config --cppflags`   -c -o printer.o printer.cc
g++ -g -Wall `llvm-config --cppflags` -DVERSION='"0.1"' -DPURELIB='"/ 
macports/lib/pure"' -c -o pure.o pure.cc
g++ -g -Wall `llvm-config --cppflags`   -c -o runtime.o runtime.cc
runtime.cc: In function 'void pure_sys_vars()':
runtime.cc:1401: error: 'GLOB_PERIOD' was not declared in this scope
runtime.cc:1405: error: 'GLOB_ONLYDIR' was not declared in this scope
make: *** [runtime.o] Error 1


>>> interpreter.cc:2243: warning: passing negative value 'INT' for
>>> argument 2 to 'static llvm::ConstantInt* llvm::ConstantInt::get 
>>> (const
>>> llvm::Type*, uint64_t, bool)'
>>
>> Those are annoying but harmless. I don't get them.
>
> I added the appropriate cast to uint64_t, so that should be fixed  
> now, too.
>
>>> interpreter.cc: In member function 'llvm::Value* interpreter::fbox
>>> (Env&, bool)':
>>> interpreter.cc:3269: warning: control reaches end of non-void  
>>> function
>>> interpreter.cc: In member function 'llvm::Value* interpreter::fref
>>> (int32_t, uint8_t, bool)':
>>> interpreter.cc:3494: warning: control reaches end of non-void  
>>> function
>>
>> I don't get these either, probably a bogus warning, but I'll have  
>> a look
>> at that, too.
>
> These warnings are certainly bogus, probably related to:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16558
> You can just ignore these, and they should go away when you upgrade  
> to a
> newer gcc version.

I don't think Apple will upgrade the version of gcc in Xcode for  
Tiger (Mac OS X 10.4) to anything newer than 4.0.1; I don't expect  
they'll release a new version of Xcode for Tiger beyond version 2.5.

Xcode 3.0 for Leopard (Mac OS X 10.5) currently also uses gcc 4.0.1  
by default, though 4.2 is either available from Apple or will be  
available (not sure which since I don't have Leopard on this machine;  
I just see a preview of gcc 4.2 for Leopard on Apple Developer  
Connection released in August 2007 and then Xcode 3.0 released in  
October 2007).

Xcode 1.5 for Panther (Mac OS X 10.3) only provides gcc 3.3.

We have newer versions of gcc in MacPorts that I can make the pure  
portfile use if that becomes necessary. Except that your Makefile  
calls g++ by name, but that's not what MacPorts calls it. For example  
MacPorts installs g++ from gcc 4.3 as "g++-mp-4.3". It also sets the  
CC, CXX and CPP environment variables to match, so maybe the Makefile  
should use the CXX variable if set.