In file included from ../sdk/lib/3rdparty/libwine/debug_ros.c:9:
../sdk/lib/3rdparty/libwine/debug.c: In function 'get_temp_buffer':
../sdk/lib/3rdparty/libwine/debug.c:343:33: warning: passing argument 1 of '_InterlockedExchangeAdd' from incompatible pointer type [-Wincompatible-pointer-types]
idx = interlocked_xchg_add( &pos, 1 ) % (sizeof(list)/sizeof(list[0]));
^~~~
In file included from ../sdk/include/crt/mingw32/intrin.h:98,
from ../sdk/include/crt/intrin.h:1017,
from sdk/include/psdk/winnt.h:48,
from ../sdk/include/psdk/windef.h:202,
from ../sdk/include/reactos/wine/debug.h:26,
from ../sdk/lib/3rdparty/libwine/debug.c:32,
from ../sdk/lib/3rdparty/libwine/debug_ros.c:9:
../sdk/include/crt/mingw32/intrin_x86.h:215:70: note: expected 'volatile long int *' but argument is of type 'int *'
__INTRIN_INLINE long __cdecl _InterlockedExchangeAdd(volatile long * Addend, long Value)
~~~~~~~~~~~~~~~~^~~~~~
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
Dynamically check for sys/types.h and pid_t in wine config.h
Use TARGET_xxx defines instead of _X86_ as this is undefined by GCC
Add some sense in include directories management by using interface
libraries
Fixes GCC 8 warning:
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:521:5: error: this 'for' clause does not guard... [-Werror=misleading-indentation]
for (i=(int)uReadSize-3; (i--)>0;)
^~~
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:529:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
if (uPosFound!=0)
^~
These are required by latest mingw-w64 stl and we are mixing this with our crt headers.
Define _CRT_NO_POSIX_ERROR_CODES in all modules that define their own constants.
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.
Running out of pool is likely at least during kmtest:ExPools.
There is a chance of crashing when dereferencing these null pointers -- but
worse, there's also a chance of overwriting the IVT or BDA if a VDM BIOS
call is in progress, which can lead to crashes in non-obvious places later.
CORE-12671
- The default format is used when no format name is specified: this is
the one we use so far in ReactOS:
<debug_class>:(<file>:<line>) <message>
with "debug_class" being "trace", "warn", "err".
- The "wine" format is the one used by Wine. It can be used when trying
to diff-compare traces for a module with the corresponding one
obtained from a Wine run. It can also be useful because the logging of
Wine-synced code assumes that the function names are automatically
added by the helper macros "FIXME()", "TRACE()", "WARN()" or "ERR()",
and not manually inside the logging string given to these macros:
for example:
FIXME("(%params) message\n", params);
displays:
fixme:<module>:SomeFunc(params) message
- The "extended" (or "ext") format is very noisy and tries to output a
lot of information; it is a hybrid of the previous two formats:
<debug_class>:(<file>:<line>):<channel>:SomeFunc <message>
Support for displaying the current process ID is added in
addition to the already existing support for thread ID.
