Reasons:
- Shared objects aren't really shared on AmigaOS
(Once two programs load the same .so, it will be loaded twice into memory instead of sharing the already available one)
- To make the program run for everyone i need to provide a subdir (SObjs/) which holds all the .so's used while compiling, otherwise some people have to go hunting for the correct .so's online.
(That completely defies the use of "shared objects")
Even worse is the fact that, if users have older .so's installed, they might experience crashes.
- There is no benefit in building ScummVM with shared objects, because even *if* a new lib version is available as an .so it won't be mandatory to immediately switch to it, because the code probably won't take advantage of it as fast.
In short:
Switchting to static builds to reduce user grief, crash reports and as a bonus have ScummVM start a little faster.
The feature is currently broken (see bug #6957 "AUDIO: ARM ASM sound code causes distorted audio on 32 bit armv6").
Fixing the feature looks highly non-trivial and since nobody volunteered so
far it's unlikely we will see any fix soon.
This allows replacing constructs like
LDFLAGS="$LDFLAGS -static-libgcc -static-libstdc++"
by
append_var LDFLAGS "-static-libgcc -static-libstdc++"
or even
append_var LDFLAGS -static-libgcc -static-libstdc++
which improves readability and reduces "code duplication", and thus
reduces the risk of introducing certain bugs (e.g. like this one:
LDFLAGS="$LDFLAG -static-libgcc -static-libstdc++"
The AAssets API was added in android 2.3, so it also requires using
the android-9 toolchain.
Using this gives a rather large speedboost to starting the ScummVM
application.
This moves the AmigaOS4 specific packaging rules from the global
ports.mk to a port specific makefile in the AmigaOS subdirectory of
the SDL backend (used for AmigaOS).
Previously, port specific makefiles were only used for cross compiling
builds and thus had a single entry in the cross compiling section of
the configure. Since AmigaOS4 is a desktop system supporting native
build, this required a second entry for when the host system is detected
as ppc-amigaos to support native builds.
However, currently this does break packaging of cross compiled builds
for Win32, OSX and Unix when done on AmigaOS4... but this is not likely
and has limited impact. To fix this, default _port_mk lines would need
to be added to the sections of the cross compiling switch for mingw32
etc. to override the AmigaOS4 OS setting of _port_mk.