config*.cmake files are constantly getting out of sync between
each other. Besides that, the parameters are not really dependent
on a target architecture, but rather on a compiler (except *ARCH)
This approach seems to be more future-prone, and allows to see
all the options in one file (there are really not that many of them)
- Updated toolchain file
- set GCC variable when using CLang in "GCC mode"
- Properly retrieve GCC support libraries
- Various flags needed to get this going
in favor of add_compile_options and the like with generator expressions
Also take this as an opportunity to remove the C++11 standard hack, GCC 8 now defaults to C++14
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
Since binutils can not add this, we re-introduce pefixup.
It searches for the exported symbol '_load_config_used',
and uses that to fill out the LOAD_CONFIG directory in the PE header
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.
