For MSVC, marking the section as discardable will do this automatically.
For GCC, we use a linker script that places it after the .reloc section
(which should be the last "real" section, check ld --verbose output for the
default linker script).
This fixes what seems to be a regression from r55835 (!).
This prevents some errors like this one:
In file included from ../dll/win32/wldap32/ber.c:27:0:
../sdk/include/reactos/wine/debug.h:378:48: error: '__wine_dbch___default' defined but not used [-Werror=unused-const-variable=]
static struct __wine_debug_channel * const __wine_dbch___default = &__wine_dbch_##ch
^
../dll/win32/wldap32/ber.c:29:1: note: in expansion of macro 'WINE_DEFAULT_DEBUG_CHANNEL'
WINE_DEFAULT_DEBUG_CHANNEL(wldap32);
^~~~~~~~~~~~~~~~~~~~~~~~~~
Up to CMake 3.3 LINK_DEPENDS was ignored in non-Makefile generators. See also http://www.cmake.org/pipermail/cmake/2010-May/037206.html. Since CMake 3.4 it is no longer ignored, but requires CMP0005 policy to be set to NEW and it requires a full path which was already correctly used on GCC, but not on MSVC builds.
* [CMAKE] Fix for CMP0018
The new behaviour lets us explicitly disabling position independent code, avoiding the need to change undocumented variables
* LINK_DEPENDS is semicolon separated
* [CMAKE] Fix for CMP0005
it seems impossible to have cmake correct escape PROXY_CLSID_IS so move it to the header
_IMPLICIT_LINK_DIRECTORIES
Othrewise, if you link a RC module with a static C library (as done for
fusion DLLs), you get the standard C libraries from GCC. This is not
what we want.
This might have to be done for MSVC builds. Check build.ninja to verify
this.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
ReactOS/Windows headers contain lots of structures whose last field is
fieldName[ANYSIZE] or fieldName[1].
Starting with GCC 4.8, gcc considers that accessing items [2], [3], ...
are undefined operation, and may optimize those accesses by removing them!
Add flag -fno-aggressive-loop-optimizations to prevent this unwanted behaviour.
