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.
When I developped the original implementation of Pokemon Stadium Japan jpeg decoding ucode
I tested it with Rice video plugin and cheated a little bit to get some sensible results
(I changed the UV rescaling a bit and perform erroneous Y1Y2 swapping). Other video plugin
didn't support YUV16 texture format so comparison wasn't possible.
Recently, I played a little bit with Glide64mk2 and noticed that without aformentionned hacks
the jpeg decoding was performing successfully. That's why I think there is a bug in Rice plugin
and that I can delete my hack from jpeg decoding ucode.
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
