The SDK's Makefile archives libGoldHEN_Hook.a with llvm-ar, which the runner's
clang package does not pull in, so the ci_ghplugin job failed with
"llvm-ar: not found".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The toolchain file hardcoded bin/linux for create-fself and readoelf, and
build.bat only ever shelled into WSL. On a Windows host with the toolchain
installed for Windows, a generated project could not be built at all.
Pick the host tool directory from CMAKE_HOST_WIN32/APPLE (still overridable
via -DOO_PS4_TOOLCHAIN_BIN for mixed setups), and have build.bat build
natively whenever OO_PS4_TOOLCHAIN is visible from Windows, falling back to
WSL otherwise. The native path needs a single-config generator because the
Visual Studio generators cannot drive this cross-compile, so it looks for
Ninja on PATH and then in the Visual Studio install.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A GoldHEN plugin is not a plain PRX. The loader enters the module at _init,
which the GoldHEN SDK's crtprx.o forwards to module_start/module_stop. Built
the stock way it links without complaint and then silently never loads on
console, so add_orbis_target(TYPE GHPLUGIN) applies all three differences:
crtprx.o instead of crtlib.o, -e _init, and SceLibcInternal/SceSysmodule
instead of c/c++. It also checks for the SDK up front and fails with install
instructions rather than producing an unloadable artifact.
The scaffolded starter plugin shows a PS4 notification from module_start. It
is emitted as C++ with extern "C" entry points -- generated projects are
project(<name> CXX), and without that the mangled names leave crtprx.o's _init
unresolved.
Reachable as --type ghplugin (aliases: goldhen, plugin) and as a fourth entry
in the GUI wizard. CI installs the SDK and builds one, since a plugin that
links but cannot load is exactly the failure unit tests cannot catch.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
create-fself output (eboot.bin, .prx, .sprx) is SELF-wrapped, not plain ELF.
Raw-ELF loader tools identify a file by its magic bytes rather than its
extension, so they cannot load those no matter what the file is renamed to.
Copy the validated .oelf to <name>.elf as well and expose the path as the
ORBIS_ELF_PATH target property, so those tools have something to point at.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sets cmake.configureOnOpen to false so the CMake Tools extension does not try
to drive the project itself. Outside a WSL/Remote-WSL session it picks a local
MSVC kit and configures with cl.exe, which cannot parse the toolchain file's
clang-style flags (-fPIC, -isysroot) and fails confusingly. Building goes
through tasks.json -> build.bat/build.sh instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
