The static Makefile is the only build. GitLab CI and the GitHub workflows
build with it, with the same lanes and toolchains; the MSVC workflow and
the CMake-only macOS universal-binary script go, as nothing builds them.
The Readme describes the Makefile build.
Builds parallel_gamecubewii_libretro for every lane .gitlab-ci.yml covers:
unix (Linux x86_64/aarch64), webos, win64 (MinGW-w64), osx (x86_64/arm64,
CROSS_COMPILE), ios-arm64, tvos-arm64, android-arm64 and android-x86_64.
The source lists and per-library flags follow what the CMake LIBRETRO=ON
build links into the core, without the units only the standalone frontends
use. The per-platform configure results for curl, libusb, libiconv and mGBA
are checked in under Externals/<library>/makefile; the remaining generated
files are produced by the Makefile under obj/gen.
The Android input backend's JNI entry points belong to the Android app and
are left out of the core, which links with --no-undefined everywhere.
The Windows code builds against MinGW-w64 headers older than 12.0 as well:
D3D12 includes d3d12sdklayers.h explicitly, and the constants, declarations
and const-correct pointer types those headers lack for D3D12, device
notifications, the Wii Remote Bluetooth path, the IOS IP stack and thread
naming are provided locally.
cURL tries to find ZSTD anyways due to the lack of setting it in CACHE, and for both ZLIB and ZSTD if we had done find_package previously, cURL would still use ZLIB/ZSTD regardless of the set variable.
The bug in CVE-2025-0665 causes crashes on Android 11 and above, as the default fdsan behavior was changed to abort when a violation is found.
While curl 8.17.0 is the latest release, we can't upgrade to it right now due to mbedtls 2.28.0 (which we are currently using) being incompatible with it.
Co-Authored-By: OatmealDome <[email protected]>
For some reason, when this is included, the linking step creates a temporary file in %TEMP% with a random name; the file is deleted afterwards and a new random name is used on a later build. Because this file doesn't exist on a later build, curl gets re-linked each time, and then all of the projects that depend on curl also get re-linked. This adds around 10 seconds to the build time even for small changes.
To make things worse, I don't think libcurl.rc does anything useful since we statically link curl; I believe the metadata contained in it only applies when building a dll. (It does seem to be included in curl.lib, but gets discarded when linking Dolphin.exe.)
See Build\x64\Release\curl\curl.tlog\Lib-link-cvtres.write.1.tlog for the log that shows this path (the file is also mentioned after setting Tools -> Options... -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity to diagnostic, but not in a useful way).
* moves dolphin-specific settings out of Base.props
* creates exports.props for externals, allowing to easily import
individual Externals
* corrects some cruft that accumulated and probably contributed
to msbuild overbuilding