On Wed, at 12:03 AM, Chris Ballinger < appears that this version no longer runs on macOS 10.12.1, either inģ2-bit or 64-bit mode. ![]() I can looking at fixing it once I have some time. On Wed, at 12:06 AM, Alexei Svitkine Are there any error messages in Console.app? Solve your lowmem / memory mapping issue - but should solve the JIT one.) Use those files rather than trying to generate them first. So to support clang, it should be a matter of changing the build to just Reply to this email directly, view it on GitHubīy the way, if you want to take a stab at the JIT stuff, here are the x86Īnd x86_64 files generated by the GCC-based build. You are receiving this because you are subscribed to this thread. I don't mind running without JIT as long as I can play some of these old Locations with dynamic addresses but it doesn't quite work as expected. There's a lot of low level hacks regarding hardcoded memory locations thatĭon't translate well to modern systems. ![]() On Tue, at 2:57 PM, Chris Ballinger spent a few days trying to fix the kernel data memory stuff andĮventually gave up because I don't understand how it works. Said, probably simplest would be to have the preprocessed generated filesĬhecked in. Those instruction files as ASM source files and then they can be maintainedĪs any other source file - with only challenge is generating them for newĬPU architectures - something that's not relevant very often. To change how we generate the assembly - for example we could just add More complicated solution would be to add support to Clang to compile the I think that's simplest solution and should be pretty easy to set up. 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? "Cannot create SHM segment for Kernel Data" - kernel_data_init/shm_map_address failure: shmget/shmat alternatives.Running "lowmem" corrupts the mach-o executable, so that is removed from the build phase.I had to disable/remove JIT, which no longer seems to compile with clang, due to the global register issue:.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. 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 Comments
Leave a Reply. |