I would like to suggest to allow the use of Cygwin as development platform.
This is not intended for providing builds for this environment (although SCUMMVM can be already built on it without problems), but for having an easy way for testing POSIX code on Windows.
There could be some alternatives, like the (defunt) Microsoft POSIX subsystem, the (also defunct) Windows Services for UNIX or the WSL1 and WSL2, but they are all painful experiences, at least for me, especially when debugging graphical applications connected to an X server or working with physical devices (try to believe). Alternatively, it is also possible to make a full virtual machine by using emulators like QEMU, but it has not the same advantages of having the code running natively, especially when sharing the same files..
So, this should be seen as a tool for developers, nothing more than that, because at the time of writing this seems to be the best and most comfortable way for debugging a change to the ports using POSIX code.
However, to avoid unintentional execution, the user must activate the support for Cygwin by providing --enable-cygwin-build at configure time, otherwise the process will halt again.
Even when support for Cygwin is activated, a warning message is still shown to the user, for informing him on what he is doing.
Some systems have fseeko but you need to check that off_t is a 64-bit
value (and this requires some magic incantation on some platforms),
others need fseeko64(), Windows has a different symbol, and then some
systems only have an fseek() that's limited to <2GB files.
This is a first step in trying to improve this.
We're using a newer toolchain there, but macOS 10.4 and 10.5 still rely
on an ancient version of GDB which chokes on C++11 symbols (such as
decltype(nullptr)), even when forcing DWARF-2 symbols only with -gdwarf2
-gstrict-dwarf.
-gstabs+ is more limited, but at least that one works with GDB, so use
it when making a debug build for those systems.
It appears a lot, and these casts are intentional and look safe.
Example:
../scummvm/engines/glk/alan3/actor.cpp: In function 'Glk::Alan3::ScriptEntry* Glk::Alan3::scriptOf(int)':
../scummvm/engines/glk/alan3/lists.h:35:52: warning: converting a packed 'Glk::Alan3::ScriptEntry' pointer (alignment 1) to a 'Glk::Alan3::Aword' {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned pointer value [-Waddress-of-packed-member]
35 | #define isEndOfArray(x) implementationOfIsEndOfList((Aword *) (x))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
../scummvm/engines/glk/alan3/actor.cpp:38:84: note: in expansion of macro 'isEndOfArray'
38 | for (scr = (ScriptEntry *) pointerTo(header->scriptTableAddress); !isEndOfArray(scr); scr++)
| ^~~~~~~~~~~~
In file included from ../scummvm/engines/glk/alan3/actor.h:25,
from ../scummvm/engines/glk/alan3/actor.cpp:22:
../scummvm/engines/glk/alan3/acode.h:453:8: note: defined here
453 | struct ScriptEntry { /* SCRIPT TABLE */
| ^~~~~~~~~~~
-fsanitize=undefined implies -fsanitize=alignment, so we need to define
SCUMM_NEED_ALIGNMENT for UBSan builds, otherwise many false positives
will be reported, such as for engines/scumm/smush/codec47.cpp.
That's also a good way of having more tests for the SCUMM_NEED_ALIGNMENT
code paths during development :)
Add the GameController framework to the project and enable support for
controller user interaction in the Info.plist file. This allows for
Game Controller compatible devices to notify the application when
connected.
Add GameController framework to configure and ports.mk if not using
Xcode to build the target.
This allows to save some space on constrained devices which still allow
for command line.
Enable this space saving on DS and enable back command line support.
Cleanup old workaround for 3DS.
- Updated Emscripten to version 3.1.8 (+ additional patches)
- Support for dynamic plugins
- Adding ScummvmFS with support for HTTP Range Requests for game data
- Automated games/demos bundling and ini config generation during build
- Allow passing CLI arguments via fragment identifier of the website (i.e. scummvm.html#—debuglevel=9 )
- UI improvements with nicer status messages, splash screen + favicon
- Fixed HiDPI handling and responsiveness
- Bugfix: Don't crash if gamepad support isn't available
__attribute__((used)) here comes from Fedora which uses LTO by default
but this is a GCC-ism, so let this code compile if the compiler is not
GCC-compatible.
Adding the sanitizer flags to the PLUGIN_LDFLAGS fixes link errors
for the plugins when asan, tsan, or ubsan is enabled.
Adding the original LDFLAGS to PLUGIN_LDFLAGS means we no longer needs
to use both in the link command for plugins.
-mlongcall -Os would work until ScummVM 2.2.0, but now the engines are
too big to fit in a single static binary on Mac PowerPC.
(On ELF platforms, some flags like -Wl,--relax or -Wl,--gc-sections
can be used as well, but macOS uses Mach-O, and its old linker doesn't
have as many workarounds. -Wl,-dead_strip helped a bit but that's not
enough and you start hitting ld internal errors.)
So, recommend dynamic plugins on Mac PPC, now, and drop -Os -mlongcall
since working around the linker limits is not possible anymore. Using
compiler defaults probably means less bugs when using such an obscure
toolchain, anyway.
(Making a static release it still possible, but only with a very small
set of engines.)
codesign didn't exist on Tiger, and didn't have a --deep option on
Leopard.
Moreover, it was rarely used on these older systems, and previous
releases of ScummVM on Mac PowerPC weren't signed either.
