Best way to compile for Mac OsX?
Archives Forums/MacOS X Discussion/Best way to compile for Mac OsX?
| ||
| Only a few percents of my customers have a MAC, so I offer a version of my game Intermezzo" also for this platform: http://www.midimaster.de/download/InterMezzo.app.zip Now a customer tells me, that "Intermezzo" is freezing on OsX10.7. It seems to be a problem of BlitzMax or XCode or OsX or combination of it. And after reading a lot of topics here I'm a little confused about what to do now... I compile the software on a MAC Mini OsX 10.5 with (i think..) XCode 4.2. I want to offer one common *.app-file of the game for all OsX versions. What should I change now? What install? What future problems are to be expected? |
| ||
| Did you happen to build it with GUI mode disabled? It's just that it starts up okay but no window appears, and all the menu items are disabled, and on further investigation (under gdb), it appears to be idling in a runloop, but not the GUI runloop? |
| ||
| Here is the error I get running it from command line: ./InterMezzo.app/Contents/MacOS/InterMezzo 2013-01-30 11:19:47.923 InterMezzo[4058:707] *** -[__NSArrayI objectAtIndex:]: index 8 beyond bounds [0 .. 7] If this doesn't help perhaps you could upload a debug build. |
| ||
| Oh, I missed that error. Freaky. |
| ||
| brucey: What you descripe is exactly, what the customer saw too! I did not forget to set "Build GUI app". And on 10.5 and 10.6 it runs perfect. How far did you get? Did you see the player name input box? skidracer: strange... there is no array with bounds [0...7] in the game. I could of course upload a DEBUG version, if this would help. What did you mean with "from command line"? |
| ||
| NSArrays are only internally used a few times in BlitzMax and quite a few in MaxGUI. Each new version of MacOS and iOS tighten up their internal error checking as good security means making sure apps don't go out of bounds. So, I just had a quick squizz and my guess is it's a MaxGUI issue with a gadget where you are indexing an item beyond the count. MaxGUI should be catching this in debug mode so it will be nice to add a fix once we work out which command is causing it. |
| ||
| Did you see the player name input box? There were no windows displayed whatsoever. |
| ||
| @skidracer sorry, but there is no itemlist, which would fit to the problem. I only use "item" in two situations. One ist the a menu list of 4 entries for recent open files. One ist the list of toolbar items, which has 16 elements Print CountGadgetItems(Toolbar) the only coincidence strange thing is only the first 7 contain "differerent " pictures. The following only contain a (still) transparent area of the image strip as placeholder for future items. |
| ||
| I will see what a gdb stack trace says at work tomorrow. I'm guessing something needs fixing in CocoaMaxGUI toolbar code. |
| ||
| OK, gdb didn't help. Either snow leopard has quite different error trapping or your app is using multi threading or something else is stopping me getting a sensible stack trace. Anyway, I am happy to test if you upload a debug build, maybe with toolbar functionality removed? |
| ||
| My gdb backtrace implies the GUI didn't start... |
| ||
| at first thank you for your engagement. It is good to know somebody helps me... @skidrcer: The app does not use multi threading. now... that's what i prepaired for the next tests: I updated to BlitzMax 1.48 to compile with the best update. Then I compiled three apps in debug mode on my osx 10.5: 1. TestMacOsx107.app some random colors in a blitzmax window without GUI. 2. TestMacOsX107GUI.app An app with GUI elements: A combination of the Blitzmax document code examples for CreateMenu(), CreateToolBar() and CreateCanvas(). Needs toolbar.png 3. Intermezzo.App again my game, but now in debug and BlitzMax 1.48 Could you please test all three, whether they run on 10.7 and/or 10.8? you can download a ZIP-file containing all three from here: http://www.midimaster.de/temp/testosx.zip |
| ||
| 1 and 2 work fine :-) 3 has the same issue as before. It starts, sets the menus (disabled), but shows no window. Output as so: DISABLE TOOLBAR 0 16 DISABLE TOOLBAR 1 16 DISABLE TOOLBAR 2 16 DISABLE TOOLBAR 3 16 DISABLE TOOLBAR 4 16 DISABLE TOOLBAR 5 16 DISABLE TOOLBAR 6 16 DISABLE TOOLBAR 7 16 DISABLE TOOLBAR 8 16 2013-01-30 22:36:16.070 InterMezzo.debug[93074:1307] *** -[__NSArrayI objectAtIndex:]: index 8 beyond bounds [0 .. 7] edit: I don't think you can disable something that doesn't exist ;-) |
| ||
| If the icon is "blank" for a given index, I think it realises this and sets that as a separator. The glue does this :
if( v>=0x1070 ){
[toolbar insertItemWithItemIdentifier:NSToolbarSpaceItemIdentifier atIndex:index];
}else{
[toolbar insertItemWithItemIdentifier:NSToolbarSeparatorItemIdentifier atIndex:index];
}
Presumably, an NSToolbarSeparatorItemIdentifier (pre 10.7) is counted as an object in the array, but an NSToolbarSpaceItemIdentifier (10.7+) is not? |
| ||
| thats interesting! I added this debug lines here: Function DisableAllTools() Local i% For i= 0 To 15 Print "DISABLE " + i + " " + CountGadgetItems(Toolbar) DisableGadgetItem Toolbar , i Next End Function The first value of this debug line is current number of item, which I want to disabled and the second value is what CountGadgetItems(Toolbar) return as number of items. So I cannot disable a item which is a separator? But the 3rd and 7th entry are already separators. See this picture:  And how to differ them? On 10.5 I have access to the"door" icon with 0, and to the "floppy disk" icon with 5: Const TOOL_EXIT%=0 , TOOL_PLAY%=1 ,TOOL_LOAD%=4, TOOL_SAVE%=5 , TOOL_HELP%=6 , TOOL_PARA%=8 .... EnableGadgetItem toolbar, TOOL_SAVE .... EnableGadgetItem toolbar, TOOL_PARA EnableGadgetItem toolbar, 9 and also to the "gearwheel" item with 8. And you can see icon 9 is not completely empty( little point"). I can access it too! Now it would be interesting, if the "floppy disk" icon has to be accessed on OsX10.7ff under the number 4? This would cause that the "gearwheel" then would be 6 and the "little point" would be 7. And now 8 would fire an error! Ok! I will write an workaround just to see what happens... But not tonight... in germany its now 1:50 and i really have to go to bed. |
| ||
| Away from topic: Since 10.8+ Gestalt is deprecated. Maybe the version-checks need an update? |
| ||
| You can install Mac OS X on VirtualBox using a retail dvd, tonymacx86's iBoot, and a software driver package called multibeast. |
| ||
| ok... here is the next update of my game. Now with a workaround at the "toolbar" problem. you can download it from here: http://www.midimaster.de/temp/InterMezzo.dubug.app.zip I added some more debug marks to see, where the next "feature" of osX10.7 is... I think it is time for sending a bug report to "MaxGUI Bug Reports", not because of my mistake, but of the fact, that TOOLBAR items are now counted in different ways on OsX10.6 and OsX10.7. The "gearwheel" item is item no. 8 on 10.6 but seems to be item no. 6 on 10.7. thank you for your help You could test this for me by doing this: if the game (ever) starts, enter a name and a age of one player. Then please click at the "gearwheel" icon of the TOOLBAR. In the console it should appear a protocol text "switch toolbar 8", but I expect it will come "switch toolbar 6". |
| ||
| Well, I should start by saying my granny would be proud - I answered the first question correctly :-) Although I am rather embarrassed to admit my German is not so good as it probably should be… Anyhoo. On a bright note, the program now happily runs! Yay! Sounds work fine. The gearwheel icon seems to be disabled - or at least, it doesn't do anything. The help icon does nothing either - although the help menu works (but links to the wrong pdf!) Other debug output appears on the console now. So, it is working much better now! |
| ||
| thank you, that is nice to hear. But did you observer, what the console wrote, when you clicked at the gearwheel icon? Is the message "switch toolbar 8" or "switch toolbar 6" or whatever... What message appears in the console, if you click on the book icon? Is it "switch toolbar 7"? What do you mean with "the wrong pdf". Didn't it open the german manual pdf? I immediaely will send it to my german customer, so he can make a first test. thank you brucey for supporting me! |
| ||
| did you observer, what the console wrote, when you clicked at the gearwheel icon? There was no text when I clicked on the gearwheel icon - almost as if the icon was disabled. (well, when you click on the "back" icon, it changes colour as you click it. This click indicator does not occur with the Help or gearwheel icons) When I say the wrong PDF, it looked like a PDF for a different program. |
| ||
| could you see any text message, when clicking on the "floopy" or "folder" image? I will have a look on the pdf problem.... |
| ||
| No, there is no debug when those are clicked on. Here's the log : Hope this helps... |
| ||
| Ah! a file window! Thats wrong! this filebox should appear, when I click on the "floppy" or the "folder" icon. Now it becomes a fact: 10.5 handles TOOLBAR ITEMS different the 10.7: They have different numbering. |
| ||
| Disk = Floppy (I hope I didn't confuse things) At no time was the gearwheel icon ever enabled. I'm not sure if this is because it is the demo version or you simply have not enabled it yet ;-) |
| ||
| That's logic now: I did not disable it. "Gearwheel" is item no. 9 on my 10.5. If I would touch it in any way (f.e. Disable GadgetItem....) you would get a crash on 10.7. My function DiableAll() disables now all elements upto no. 7 (upto "book" on my 10.5). And because the gearwheel is no. 7 on your 10.7 it will also be disabled. yes, "disk" = "floppy" I already posted a bug report to GUI forum. Who is now responsible for the next step? Is skidracer the responsible person? I fly to brasil in one hour, so I'm away for the next 2 weeks.... thank you brucey for helping me pointing out the bug. |
| ||
| Who is now responsible for the next step? Is skidracer the responsible person? Yes, I expect he will have a look at the problem at some point. There may even be a fix by the time you get back. Or at least some confirmation of the problem by others ;-) Have fun down there! |
| ||
| Sorry this has taken so long to address. I have uploaded an experimental fix for cocoamaxgui.mod/cocoa.macos.m here: http://sourceforge.net/projects/maxgui/files/cocoa.macos.m/download Replace existing file and rebuild modules to test. Not yet tested on Mountain Lion, any help much appreciated. |
| ||
| works fine |
   |