The pieces were nearly all in place already - CMakeLists has detected
riscv64 and set RISCV64 since the backend landed - so this is mostly a
matter of not hardcoding loongarch64 in the cross-build plumbing:
- setup-loongarch64-cross.sh becomes setup-cross.sh <target>, taking the
triple and dynamic linker name from the argument.
- b.sh gains --riscv64, and the GL stub block is keyed off a compiler
variable rather than a loongarch64-only flag.
- New cmake/Toolchains/riscv64-linux-gnu.cmake, mirroring the existing one.
The SDL carve-out moves from LOONGARCH64_DEVICE to a new HEADLESS_CROSS
option set by b.sh. That flag was keyed off the target architecture, which
is also true when building natively on such a machine - harmless so far,
but riscv64 hardware that people actually build PPSSPP on exists, and it
should still get the normal SDL frontend.
Both toolchain files now find qemu rather than assuming the static build:
Debian ships the static binaries in qemu-user-static and the dynamic ones
in qemu-user, and only the latter is available on some releases. Neither
being present is fine too - it just means no compile-check programs run.
Verified by a clean loongarch64 build; riscv64 is untested so far, the
toolchain isn't installed here yet.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
The GL stub generation in b.sh and setup-loongarch64-cross.sh harvested
symbols from hardcoded /usr/lib/x86_64-linux-gnu paths. On any other host
those simply don't exist, and neither script treats that as an error - so
the stub silently fell back to the handful of GLX symbols listed inline,
which isn't enough for GLEW's static archive to link against.
Ask the host compiler for its multiarch triplet instead.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
1. postproc now looks for postprocess.h (there is no postproc.h header).
2. pkg-config fallback condition now works (find_path/library set the
variable to ${var}-NOTFOUND but it was checking for an empty string).
Creating toolchain for NVIDIA jetson by correctly linking to the graphics library that should be used
The current Libglx.so library in L4T that is installed comes into conflict and the detection of the GPU is not correct
This new module should be able to handle both libraries in the regular
paths and fallback to pkg-config.
It is also able to find dynamic libraries, not just static libraries.
It will generate imported targets with the name FFmpeg::<lib> that you
can use in your scripts.
The way it’s used in our main build script has been updated to match.
We also won’t link external libraries used by ffmpeg automatically since
it is not reliable and depend on custom options.
You should use a proper static build with no external dependencies or
a shared build that will have the proper dependencies listed.
Instead of relying on manually passed down flags from CMake,
we now have ppsspp_config.h file to create the platform defines for us.
This improves support for multiplatform builds (such as iOS).
This was using hardcoded locations that don’t work with alternate Xcode
installations. Use “xcrun” instead to find where the SDK is.
And remove unused code.
Henrik RydgårdandClaude Opus 5
oltolm
Eric Warmenhoven
Serena
Unknown W. Brackets
李通洲
Gleb Mazovetskiy
orbea
kaiomatico
DuIslingr
Florin9doi
Carlos Estrague / Mrc_munir
hissingshark
Greg V
Conn O'Griofa
Florent Castelli
Jools Wills