mcarans wrote: ↑Mon Aug 25, 2025 9:53 pm
What is the process for debugging failures like this? Is there a way to get much more detailed logging so I can track down where it is failing?
Check for the files stderr.txt and stdout.txt in oolite.app while the game is running. Do they contain any messages? If the game terminates normally these will be auto-deleted, be aware of that in case you can't find them.
You can also try editing logcontrol.plist. At the top of the file there is a commented out
_override = yes; line. Remove the comment and activate it, it will force printing of
all log message classes.
If all else fails you can always try the universally standard debug method: printfs in the code - or, in our case, NSLog(@"your message here") statements. They use the same format specifiers as printf. Sprinkle some of those after the OpenGL extensions have been printed out and see where NSLogs stop getting printed. With patience you can narrow it down to the exact line that fails. Sounds like torture? Sure! Been there, done that, got the t-shirt, used it as cleaning rag, threw it in the trash and then did it again. That's part of the price of admission if you want to set up a build environment for Oolite from scratch.
Which version did you build? Oolite uses 1.2.13 and the patch with the changes may not be entirely applicable for later SDL 1.2 versions. Maybe it works, but there are no guarantees and I believe that a lot of the patch changes are already present in more recent SDL 1.2. You may need to ensure tha all changes made are indeed necessary and do not duplicate existing functionality if you have built SDL later than 1.2.13.
I also built gnustep 1.31.1 (using gcc).
Did you include TLS support when you built it? It is absolutely critical that you have TLS in gnustep, or 99% of OXPs cannot be downloaded due to living in https domains.
I think it would really help if there were some basic checks on Oolite startup to confirm important libraries like OpenGL, OpenAL, SDL, Javascript etc. can be called and hence rapidly narrow down the source of problems. Could such tests go in main.m before the application is started?
What do you mean exactly by "getting called"? Windows already has checks when loading dlls, that they contain all the functions the application asks for during its startup. If an application contains calls to a function that's not there you will get an error message along the lines of "Entry point for function whatever could not be located in whatsitsname.dll" and the app doesn't start. As long as all functions can be linked dynamically at run time, the app starts. Now, if a function in a dll is buggy or has strange interactions with the OS, that's something that we can only find out at the time of executing that function.
Oolite already has plenty of sanity checks when loading up libraries like OpenAL, JS, etc. Not sure about gnustep itself, but I am not sure about how you would add checks for gnustep's health either.
