![]() ![]() Due to the heritage of PPC Mac OS the ABI is the same One other thing I tried was setting the llvm-target in the custom target JSON Looks like it’s looking for an aux entry to determine the symbol type Point at the new library and tried building again: /home/wmoore/Source//autc04/Retro68-build/toolchain/lib/gcc/powerpc-apple-macos/9.1.0/././././powerpc-apple-macos/bin/ld: /home/wmoore/Projects/classic-mac-rust/target/powerpc-apple-macos/release/libclassic_mac_rust.obj(classic_mac_rust-80e61781bab75910.classic_mac_rust.9ba2ce33-cgu.0.rcgu.o): class 2 symbol `hello_rust' has no aux entries Powerpc-linux-gnu-objcopy -O aixcoff-rs6000 /src/target/powerpc-apple-macos/release/libclassic_mac_rust.a /src/target/powerpc-apple-macos/release/libclassic_mac_rust.objĮxamining the objects in the new archive showed that they were now in the sameįormat as the objects generated by Retro68. a, and it worked: docker run -rm -it -v $(pwd):/src debian:testing So I fired up a Debian docker container and tried converting That mentions that powerpc-linux-gnu-binutils on Debian knows aboutĪixcoff-rs6000. At this point I tried to find a way to convert my ELF objects to It looks like it really only supports xcoff-powermac, which was derived from Rs6000:6000 xcoff-powermac srec symbolsrec verilog tekhex binary ihex Powerpc:common xcoff-powermac srec symbolsrec verilog tekhex binary ihex ![]() Xcoff-powermac srec symbolsrec verilog tekhex binary ihex (header endianness unknown, data endianness unknown) powerpc-apple-macos-objcopy -info shows that Retro68 does not handleĮLF: BFD header file version (GNU Binutils) 2.31.1 Some investigation shows that the objects in the libraryĪre in ELF format. home/wmoore/Source//autc04/Retro68-build/toolchain/lib/gcc/powerpc-apple-macos/9.1.0/././././powerpc-apple-macos/bin/ld:/home/wmoore/Projects/classic-mac-rust/target/powerpc-apple-macos/release/libclassic_mac_rust.a:1: syntax errorĬollect2: error: ld returned 1 exit status home/wmoore/Source//autc04/Retro68-build/toolchain/lib/gcc/powerpc-apple-macos/9.1.0/././././powerpc-apple-macos/bin/ld:/home/wmoore/Projects/classic-mac-rust/target/powerpc-apple-macos/release/libclassic_mac_rust.a: file format not recognized treating as linker script : & /home/wmoore/Source//autc04/Retro68-build/toolchain/bin/powerpc-apple-macos-gcc -Wl,-gc-sections CMakeFiles/Dialog.dir/dialog.obj -o Dialog.xcoff /home/wmoore/Projects/classic-mac-rust/target/powerpc-apple-macos/release/libclassic_mac_rust.a & : Now when building the project we get… ninja: Entering directory `cmake-build-retro68ppc' ParamText documentation from my copy of Inside Macintosh Volume Ⅰ To CMakeLists.txt to have CMake link with the Rust library. Pub unsafe extern " C " fn hello_rust () -> *const u8 /target/powerpc-apple-macos/release/libclassic_mac_rust.a) With the basic workflow working I set about creating a Rust project that builtĪ static library with one very basic exported function. Sample applications and launch them in the emulated Mac. Using the LaunchAAPLĪnd LaunchAAPLServer tools that come with Retro68 I was able to build the With Retro68īuilt I set up a VM in SheepShaver running Mac OS 8.1. That allows cross-compiling applications for 68K and PPC Macs. ![]() I started by building Retro68, which is a modernish GCC based toolchain This weekend I thought I’d see if I could build a MacĪpp for it that called some Rust code. I recently acquired a Power Macintosh 9500/150 and after cleaning it up andīuilding a BlueSCSI to replace the failed hard drive it’s now in a ![]()
0 Comments
Leave a Reply. |