ADVANsCEne::convertDB() and getXMLConfig() read an ADVANsCEne .xml DAT
and write the .ddb the save-type lookup consumes, and they are the only
reason this tree carries TinyXML. Their remaining entry point,
NDS_RunAdvansceneAutoImport(), fires on CommonSettings.run_advanscene_import,
which nothing sets - and on either outcome the importer calls exit(),
which a core must not do. The lookup itself stays: setDatabase() and
checkDB() read the binary .ddb and keep driving save-type detection in
NDS_Init() and NDS_LoadROM().
advanscene.h picks up <string.h> for the memset() in its constructor,
which used to arrive through tinyxml.h.
This tree builds one target, and with the __LIBRETRO__ conditionals gone
the other three frontends cannot be configured, let alone built. Their
sources and build systems go, along with src/Makefile.am and the gdbstub
Makefile.am that included the POSIX one.
Two files under frontend/windows are not frontend code and stay: the
bundled winpcap headers, which the libretro Windows build puts on the
include path for wifi.cpp, and windriver.h, which wifi.cpp includes for
its Lock declaration. Both move up to src/ and wifi.cpp and
Makefile.libretro follow them.
Every #if on __LIBRETRO__ in the shared sources had one reachable branch
and one that could not be compiled here, so the conditions go and the
reachable branch stays. Compound guards keep the part that still
constrains something: wifi.cpp reaches the bundled winpcap headers on
_WIN32 alone, and path.h selects the libretro-common path helpers unless
DESMUME_COCOA.
The resulting object is the same size with the same symbols at the same
addresses and byte-identical .rodata, .data and .bss; .text differs only
where __LINE__ immediates moved.
Closes#125: on RetroArch Plus content arrives as a SAF URI, and
STDROMReaderInit() gated the open behind stat(), which cannot resolve one.
The gate failed, Init() returned NULL and every ROM was reported as failing
to load, even though the fopen() below it is already rfopen() via
file_stream_transforms.h and would have gone through the frontend.
Under __LIBRETRO__ the check now uses filestream_exists(), so it asks the same
VFS that will do the reading. Other frontends keep the stat() path, which also
still rejects non-regular files there.
Tested with a harness that hands the core a VFS whose paths are not real file
paths (the way SAF URIs behave): before the change retro_load_game() returns
false, after it the ROM loads and runs.
The x86 AsmJit dynarec and the arm_arm JIT are x86- and 32-bit-ARM-only,
so on aarch64 the platform=unix build must fall back to the interpreter
(DESMUME_JIT=0), matching what jni/Android.mk already does for arm64.
LibretroAdmin