I think just become C++ files with byte arrays corresponding to the You can even check in the disassembled versions of those - which So oneĮasy solution is to simply check in the file produced by GCC (one for x86Īnd one for x86_64) and just use those directly - instead of recompilingĮach time. That uses the compiler to compile a bunch of common instructions and thenĭisassembles that to get the actual x86 assembly to use at run-time. Like MacPorts.) There's a couple ways to fix this.įirst thing that's important to understand is what's broken is a build step (although I think you can still install and use GCC on OS X - via something I think the JIT stuff is the main blocker for compiling with Clang But you can also explore compiling with different I suspect if you fix the problem with lowmem, then it I think the "cannot create kernel data" error is directly related to lowmem (As long as they don't regress the existing buildĮnvironment. More important thing is that it actually runs and works - rather than howīut certainly patches are welcome to bring it closer to compiling with a
But I don't see it being a big deal since the
In terms of compiling with a more modern toolchain - well it wouldĬertainly be nice to have. If there's some issues than they can be investigated I believe SheepShaver compiled with the 10.6 toolchain should still workįine on latest OS X. Ĭom/doku.php/sheepshaver not work for you?
#Setup sheepshaver how to#
I'm not familiar enough with what the code is trying to do so I'm not sure how to fix it properly yet. This no longer seems to be allowed on modern OS X because the call to shmat in shm_map_address fails. It compiles but doesn't yet run do an issue with the kernel_data_init function involving shared memory allocation at a specific address.
#Setup sheepshaver mac os#
It's worrisome that the only remaining way to run classic Mac OS software now needs to be compiled on classic Mac OS software.
0 kommentar(er)
