Buy google chromcast. I'm looking for a good strategy to solve a problem with customers not able to start the game on OS X 10.6.8. User issue here: With the help of Google looking for 'EXC_BREAKPOINT _forwarding_ + 673' I found some hints that OS X 10.6.8 and lower might have issues with anything newer than JRE 1.7.0 u25, a version which I can't even find for download anymore. Example: Right now I see a few approaches: • Let packr try to detect somehow that it's running on. If I were you, I would ask to the end users to upgrade from OS X 10.6.8 to 10.7 which is free and I would bump the minimum requirements to OS X 10.7. ![]() ![]() Java for Mac OS X 10.6 Update 16 delivers improved security, reliability, and compatibility by updating Java SE 6. Mozilla firefox 29 0 download for mac. If they had to pay to upgrade, they could be angry but it's not the case. In my humble opinion, it would be more relevant to support the system JVM everywhere or nowhere. Supporting it only under OS X would be confusing. Poxnora uses JOGL 2, it should work under OS X 10.6.8 but not with the latest update of OpenJDK 1.7. Yes, I'm kind of at a dead-end here. Especially without a real system at hand to test this properly. For our game I've implemented a detection for 10.6, and fall back to using the system JRE in that case. To locate libjvm.dylib I search for $JAVA_HOME first, and if that fails, check for /usr/libexec/java_home. Still, in my latest round of that lasting fight, I struggle with libjvm.dylib apparently only available as a 32-bit library in Apple's 1.6 JRE, which doesn't like to load from a 64-bit (or 32/64-bit universal) packr executable. At the current state I tend to just close the case. It's not really worth fighting for a really small number of customers. I have a Mac Book Pro with OS X 10.6.8, I use it only for my tests. If one of your libraries is 32/64-bit universal, it won't work with Apple JRE:( 'a really small number of customers' who can still upgrade to OS X 10.7 for free. Personally, I'm not a big fan of switching to the system JRE at runtime in certain cases and using the 'same' JRE everywhere eases the maintenance, you don't have to work around Apple JRE-specific concerns. My Ant script does most of what PackR does (except minimizing the JRE), it uses only its native launchers if needed with the option of replacing them by portable scripts and then a flag allows to force the use of the system JRE but there is no JRE detection at runtime. I'm quite satisfied by my solution even though I haven't tested the script (replacing the native launcher) under Mac and Windows yet.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |