My customers with new MacBook Pro's have confirmed that the new version of my QuickAlarm app with the new MacRuby 0.1/LLVM works! Good job everybody!

Yes, it was a problem in LLVM, which wasn't generating code for the proper architecture. I hope this was an exception and that we won't need to target new LLVM versions each time new architectures are introduced :)

Thanks for verifying the fixes. I will release trunk as 0.10 tomorrow evening.

Laurent

On Mar 10, 2011, at 3:00 AM, Nick Ludlam wrote:

...

I can also confirm this now builds correctly. Thanks very much for the speedy turnaround, Laurent.

Out of interest, do you know why the Core i7 chip in this laptop behaves differently to the Core 2 Duo in my previous laptop? Is it perhaps just that LLVM is failing to detect the CPU correctly, and is creating code based on incorrect assumptions?

On 10 Mar 2011, at 02:27, Laurent Sansonetti wrote:

...

I got confirmation that trunk as of r5271 should work. Because of the severity of this problem, and the recent changes in macruby_deploy regarding App Store submissions, I think we should release 0.10 as soon as possible now. I will work on it.

Laurent

On Mar 9, 2011, at 4:09 PM, Laurent Sansonetti wrote:

...

Okay, I committed support for LLVM 2.9 as of r5269 and verified that no regression is introduced (the spec suite runs fine).

Please update your repository, do a rake clean, then build with the CFLAGS="-D__SUPPORT_LLVM_29__" option. Example: $ rake CFLAGS="-D__SUPPORT_LLVM_29__" jobs=8

If this fixes the problem, we might need to roll out a MacRuby release with this new LLVM soon, as I suspect the problem will hit many people.

Laurent

On Mar 9, 2011, at 2:10 PM, Laurent Sansonetti wrote:

...

Okay, API breakage, but I can reproduce that on my machine :) I will hack on it later today and post a message here once it's supposed to compile, this way you can continue testing.

Laurent

On Mar 9, 2011, at 2:03 PM, Nick Ludlam wrote:

...

Ok, well it's not failing in the same way, but it's still failing:

/usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I./icu-1060 -c ucnv.c -o .objs/ucnv.o /usr/bin/gcc-4.2 -std=c99 -I. -I./include -pipe -fno-common -fexceptions -fblocks -g -O3 -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I./icu-1060 -c encoding.c -o .objs/encoding.o /usr/bin/g++-4.2 -I. -I./include -fblocks -g -Wall -Wno-deprecated-declarations -Werror -arch x86_64 -I/opt/llvm-macruby/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-rtti -fno-common -Woverloaded-virtual -I./icu-1060 -c main.cpp -o .objs/main.o In file included from vm.h:593, from main.cpp:17: compiler.h:82: error: ISO C++ forbids declaration of ?DIFactory? with no type compiler.h:82: error: expected ?;? before ?*? token rake aborted! Command failed with status (1): [/usr/bin/g++-4.2 -I. -I./include -fblocks ...]

(See full trace by running task with --trace)

On 9 Mar 2011, at 21:34, Laurent Sansonetti wrote:

> It looks like it might take a while until I get my hands on a new MBP, so could one try the following? > > 1) Grab a copy of https://llvm.org/svn/llvm-project/llvm/branches/release_29 using svn, then build it using the same instructions in README.rdoc. I am just hoping that this new version of LLVM supports the new hardware and that it doesn't introduce API breakage. > 2) Re-build and install MacRuby trunk after doing a rake clean. > > Laurent > > On Mar 9, 2011, at 1:08 PM, Laurent Sansonetti wrote: > >> Sorry the late reply. It's probably because this version of LLVM that we use cannot target the new CPU yet. I will investigate :) >> >> Laurent >> >> On Mar 9, 2011, at 12:10 PM, Nick Ludlam wrote: >> >>> Yes, this looks like it's exactly the problem I'm having, from the look of the log, so perhaps it's a Sandy Bridge / Core i5/7 issue. Curious! >>> >>> On 9 Mar 2011, at 19:56, Richard Sepulveda wrote: >>> >>>> I have a customer that is also having this same problem with my MacRuby Mac App Store application running on his new MacBook Pro. I don't have >>>> access to this type of Mac so I haven't been able to reproduce this problem. >>>> >>>> He has tried MacRuby 0.8 and 0.9 versions of my app with the same results. >>>> >>>> I can provide copies of my app to developers that would like to try to reproduce the problem. >>>> >>>> Thanks, >>>> >>>> Richard