Open GoogleCodeExporter opened 9 years ago
First off, thank you for attempting a Mac build!
It sounds to me like your llvm-config is probably publishing those -fno-rri and
-fno-exceptions flags into our compile line. What happens when you run
"llvm-config --cflags"?
Original comment by mind...@gmail.com
on 6 Jan 2011 at 10:05
Thanks for the quick response! Here's what I get:
78,0 sean@Sean-Lynchs-MacBook-Pro:~$ llvm-config --cflags
-I/usr/local/homebrew/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -O3 -fno-common
-fno-rtti is mentioned in the configure script that comes in the tarball on
line 8528:
if test x"$lt_cv_prog_compiler_rtti_exceptions" = xyes; then
lt_prog_compiler_no_builtin_flag="$lt_prog_compiler_no_builtin_flag -fno-rtti -fno-exceptions"
I'm using llvm 2.8 from homebrew:
505,127
sean@Sean-Lynchs-MacBook-Pro:/private/tmp/homebrew-crack-0.2.1-BkhJ/crack-0.2.1$
llvmc --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.8
Optimized build.
Built Jan 2 2011 (12:08:25).
Host: x86_64-apple-darwin10
Host CPU: penryn
Registered Targets:
(none)
Original comment by seanlyn...@gmail.com
on 6 Jan 2011 at 11:55
hunh, that's interesting. From a later part of configure, it looks like those
options should be disabled for C++ code.
I'll investigate further, but as a work-around, try disabling that check in
configure - this will at least move you forward to the next problem :-)
You're only about the third person I know of to attempt to build this on a mac,
so it's extremely likely you're going to run into more problems. While we're
happy to try to help in any way we can, I have to warn you that you may have a
struggle ahead of you.
Original comment by mind...@gmail.com
on 7 Jan 2011 at 2:09
No problem. I'll give that a shot sometime today and let you know what I run
into next. I'm perfectly happy to be the Mac guinea pig.
Original comment by seanlyn...@gmail.com
on 7 Jan 2011 at 6:35
Ran into my next problem just trying to clone the Mercurial repository.
Crack.cc and crack.cc collide on a case-preserving (vs case-sensitive)
filesystem, and HFS+ is case-preserving. Filed Issue 62 for this.
Original comment by seanlyn...@gmail.com
on 7 Jan 2011 at 7:00
Thanks for attempting that - Shannon Weyrick is attempting a build on the Mac,
you might want to chat with us on IRC at #crack-lang on freenode.net. You guys
might be able to collaborate. We're currently working to release version 0.3,
but if we can get Mac portability in there quickly I'm willing to delay the
release for it.
I looked into the use of the rtti/no-exceptions options in our configure (it's
injected by libtool) and I currently believe it to be a red-herring: if the
libtool macros were generating these options, they should be preceded by
"-fno-builtins" everywhere they are used, and they are not.
Can you take a look at your generated Makefile and see where these are used
there? It might give us a hint as to which part of the configuration is
requesting them.
Also, I fumbled when I asked you for 'llvm-config --cflags', can you tell me
the output of 'llvm-config --cxxflags'?
Original comment by mind...@gmail.com
on 9 Jan 2011 at 3:42
Aah, it's in there:
501,0 sean@Sean-Lynchs-MacBook-Pro:~$ llvm-config --cxxflags
-I/usr/local/homebrew/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -fno-rtti -fno-common
-Woverloaded-virtual -Wcast-qual
And it's in LLVM_CXXFLAGS in the Makefile:
LLVM_CXXFLAGS = -I/usr/local/homebrew/include -DNDEBUG -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -fno-rtti
-fno-common -Woverloaded-virtual -Wcast-qual
And in AM_CXXFLAGS:
AM_CXXFLAGS = -I/usr/local/homebrew/include -DNDEBUG -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -fno-rtti
-fno-common -Woverloaded-virtual -Wcast-qual -fexceptions
Original comment by seanlyn...@gmail.com
on 9 Jan 2011 at 4:37
A new "osx" branch is available which contains changes specific to getting
crack compiled on OSX. Currently it builds and some non-bootstrapped tests from
the suite pass, but bootstrapped tests fail. This is under investigation, fixes
will be pushed to the osx branch as they become available.
Original comment by weyrick
on 14 Jan 2011 at 5:38
Original comment by weyrick
on 14 Jan 2011 at 5:43
Original comment by mind...@gmail.com
on 8 Apr 2011 at 1:31
Moved this to 0.5, since we're clearly not going to get to it before the
release.
Original comment by mind...@gmail.com
on 8 Apr 2011 at 1:31
update - this is once again being worked on. changes are going into default
(trunk) branch now, not osx.
Original comment by weyrick
on 26 Sep 2012 at 8:27
Issue 119 has been merged into this issue.
Original comment by mind...@gmail.com
on 8 Jan 2013 at 2:34
Original issue reported on code.google.com by
seanlyn...@gmail.com
on 6 Jan 2011 at 7:47