The *.d depends files for make just list the files used when building an
object file. Removing a file listed in such a dependency file causes make to
search for a way to recreate it. This usually cannot work because these files
aren't autogenerated.
The gcc option -MP can be used to generate empty rule for these files. Removing
a file in a dependency list will then execute this empty rule and continue with
the execution of the creation of the object file. This compilation process will
then automatically correct the dependency file.
The GCC introduced Link-time optimization in GCC 4.5 (2010-04-14). This should
be long enough available that interested users have upgraded to a compiler
supporting it.
The MSVC project already enabled WholeProgramOptimization since a long time.
Enabling it by default in GCC seems to be equally valid.
The GCC manual states for different parameters that the options for compilation
must also be used when linking. The options for compilation are stored in
CXXFLAGS and added to LINK.o to fix the behavior.
Option which need this are for example -fPIC/-fPIE or -flto.
Some linker on different platforms don't handle the garbage collection
correctly and create extreme bloated binaries. Therefore, leave it to the user
to enable this feature or not.
The POSTFIX make option is useful for distributions to compile different
versions of the plugin in parallel. The object files will be stored in a
directory with the postfix appended and the linker result will also have this
postfix appended.
The CROSS_COMPILE make option can be used to automatically prepend the prefix
to all build relevant tools to seamlessly allow cross compilation without
setting each tool name separately.
Cross compiling for MinGW32 would can be done using
$ make -C projects/unix/ CROSS_COMPILE=i686-pc-mingw32- HOST_CPU=i686 UNAME=MINGW
2. Removed inline attributes which throw errors in MSVC8. This is needed for modern compilers; they know when to inline
3. Fixed errors caused by MSVC8's incompatibility with C99 local variable declarations
nogagplz tested mupen64plus on 32-bit ppc and didn't detect any big show
stoppers with interpreter cores and the mupen64plus example rom. This makes the
PowerPC an interesting target for further tests and may reveal other endianness
problems.
nogagplz noticed on ppc32 that PIC is necessary to compile everything as shared
object. Therefore, it seems to be a better idea to have architecture specific
PIC default settings instead of checking only whether it is a 32 or 64 bit
architecture.
The g++ also exports symbols of implicit instantiations of templates. These
aren't part of the api and must not be accessed by any other part of
mupen64plus. We can use version-scripts to surpress these symbols without using
explicit instantiations of all templates we use.
