Principia fails to load on macOS Sequoia (v15.2) - Unix 25.2.0.0 Detection Error Problem Description

[1304674612]

I am attempting to run Principia on macOS Sequoia 15.2 (Apple Silicon) with a KSP 1.12.x RP-1 installation. Despite installing the required dependencies via Homebrew and manually patching the .so binary, the game fails to load the plugin and displays an error regarding OS detection and missing libraries.

System Environment:

OS: macOS Sequoia 15.2 (Kernel: Darwin 25.2.0)

Hardware: Apple M-series M4(Silicon)

KSP Version: 1.12.5 (Running via Rosetta 2)

Principia Version: principia lebesgue for 1.12.5.zip

Dependencies: LLVM 21 installed via Homebrew (/opt/homebrew/opt/llvm)

Detailed Error Message:

Steps Taken So Far:

Dependency Fix: I have installed llvm via Homebrew.

Binary Patching: I used install_name_tool to redirect the hardcoded /usr/local/opt/llvm@20/ paths inside principia.so to the correct local paths:

libc++abi.dylib -> /usr/lib/libc++abi.dylib

libc++.1.dylib -> /usr/lib/libc++.1.dylib

libunwind.1.dylib -> /opt/homebrew/opt/llvm/lib/unwind/libunwind.1.dylib

Verification: otool -L confirms all paths are correctly mapped.

Path Workaround: Created a literal directory named {0} inside GameData/Principia/macOS/ and placed the patched principia.so there to satisfy the loader's search pattern.

Permissions: Ran chmod u+w and sudo xattr -cr on the entire GameData directory.

Code Signing: Performed ad-hoc signing using codesign --force --deep --sign -.

Observed Behavior in KSP.log:
The log shows:
[LOG] Loading the x64 Principia DLL principia.so from paths: ...
[LOG] Principia DLL loaded at address 0000000000000000
The address remains 0x0, indicating a linking failure or a silent rejection by the macOS Gatekeeper/Hardened Runtime, even though the file is found.

Specific Question:
How can I get the Principia loader to correctly identify the macOS environment instead of falling back to the {0} Unix path pattern on Darwin 25.x? Is there a specific version of LLVM or a specific code-signing requirement for macOS Sequoia to prevent the null pointer load address?
I have uploaded my full KSP.log here: https://pastebin.com/B77Y618z

Here is the otool -L output of my patched principia.so:

Additional Context: I am running KSP on an external drive (or moved to local drive) and I've already applied codesign and xattr -cr.

[rnlahaye]

I will try to reproduce this at some point, but for now it might be easier to just build Principia from source.

[pleroy]

Path Workaround: Created a literal directory named {0} inside GameData/Principia/macOS/ and placed the patched principia.so there to satisfy the loader's search pattern.

This is not going to do anything useful. The message that prints the pattern may not be very user-friendly, but the preceding log entry shows that it properly substituted x64 for the pattern.

[LOG] Principia DLL loaded at address 0000000000000000

The error handling is faulty here, but basically dlopen failed. I suggest tracing the system calls (not sure how it's done on macOS, maybe dtruss?) to figure out why dlopen is unhappy.

I have uploaded my full KSP.log here: https://pastebin.com/B77Y618z

This is not the full KSP.log.

[MrJeremyFisher]

This is happening to me as well. On Ubuntu 24.04.4. Building the binaries locally fixed it.

[pleroy]

This is happening to me as well. On Ubuntu 24.04.4. Building the binaries locally fixed it.

This is somewhat surprising because, while we have seen problems with exotic Linux distros and with macOS, Ubuntu has been very smooth. Maybe we broke Ubuntu, maybe there's some kind of incompatibility, but we will never know because you are not giving us any information to investigate the problem. 🤷‍♂️

[MrJeremyFisher]

What do you need? I am having the exact same issue as the original reporter and building locally fixes the problem for me. I can provide logs but they are, again, the same as those provided by the original reporter.

[pleroy]

We need the logs mentioned here, if they exist.

The original reporter didn't even give us a full KSP.log (they filtered it somehow), so at least having the full log would be an improvement. It would also be good to have a trace of system calls during execution of the "failing" binary. (Not sure how this is obtained on Ubuntu, maybe strace?)