by hand!
Motivation is to fix the following warnings at configure-time for *MSVC x86 dbg* :
-- dcomlaunch has no base address
-- netlogon has no base address
-- w32time has no base address
-- dpnhpast has no base address
-- cryptext has no base address
-- netplwiz has no base address
-- fusion has no base address
-- fusion_1_1 has no base address
-- fusion_2_0 has no base address
-- msxml3r has no base address
-- xolehlp has no base address
-- localspl_apitest.dll has no base address
This fixes CORE-14831 for *MSVC dbg* for this release-branch at least.
Meaning: It hides the effect, without fixing the cause.
It is not a sustainable solution for master yet.
We'd need to improve the python script for that.
I tested afterwards the bootup of a build configured via:
-DENABLE_ROSTESTS=1 -DENABLE_ROSAPPS=1
and built with:
MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuration
and verified that we had no relocation happening until 3rd stage desktop VBox4.3.12.
MSVC 2010SP1 (16.0.40219.1) x86 target in *rls* configuration was not
tested yet, as that up to now did never reach the desktop yet for unrelated reasons.
I will not upload an iso to sourceforge after this commit,
because it will not have any impact for our primary GCC 4.7.2 toolchain.
by hand!
Motivation is to fix the following warnings at configure-time for *GCC dbg* :
-- netlogon has no base address
-- w32time has no base address
-- rshell has no base address
-- fusion has no base address
-- fusion_1_1 has no base address
-- fusion_2_0 has no base address
-- msxml3r has no base address
-- notifyhook has no base address
-- vfd has no base address
-- msvcrt_crt_dll_startup has no base address
-- redirtest1 has no base address
-- redirtest2 has no base address
-- localspl_apitest.dll has no base address
-- load_notifications has no base address
-- custom has no base address
-- testvdd has no base address
This fixes CORE-14831 for *GCC dbg* at least for this branch.
Meaning: It hides the effect, without fixing the cause.
It is neither a sufficient fix for other toolchains/configs,
nor a sustainable solution for master yet.
We'd need to improve the python script for that.
This version (after .rsrc) works different than the
proper version I used for 0.4.12 (after .reloc).
Inserting after .rsrc as actually not correct, but Thomas believes it can
be used as a temporary trick to avoid random memory corruption upon
relocations of the kernel, caused by ROSBE-154.
I follow his advice, although when judging from practical tests only:
as long as we limit this script to NTOSKRNL like I do for releases
there have no negative consequences been observed in real life yet
even with the proper version of 0.4.12.
Up to now those problems have only been observed when used for drivers
MODULE TYPE sdk/cmake/gcc.cmake as well, like
it was tried for a moment in master 0.4.13-dev-609-g
c4d8e2a6e9
Using for drivers immediately did lead to BSODs like CORE-16183 and therefore was
mitigated in master by total disabling of the scripts for both,
kernel and drivers in
0.4.13-dev-621-g
36e9a6f8dd
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
Master remains affected by the BSOD until Thomas allows to commit there as well.
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
- C4311: pointer truncation from '<pointer>' to '<integer>'
- C4312: conversion from '<integer>' to '<pointer>' of greater size
- C4133: incompatible types - from '<x> *' to '<y> *'
- C4028: formal parameter different from declaration
_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.
MSBuild, via the VS IDE, uses response files when calling CL or LINK.
We cannot specify a custom response file on the linker command-line,
since specifying response files from within response files is forbidden.
We therefore have to pre-process, at configuration time, the linker
script so as to retrieve the custom linker options to be appended
to the linker command-line.
- Always use string pooling when building: this helps reducing the
size of the binaries due to string redundancy coming from the usage
of __FILE__ / __RELFILE__ in the debugging helper macros. Note also
that GCC builds use string pooling by default.
- Use suitable add_compile_flags() command.
- Add some explanative comments for some settings.
Some numbers (obtained with my local builds):
Before / After => Reduction
===========================
freeldr.sys : 443 KB ( 453.632 bytes) / 364 KB ( 372.736 bytes) => ~ 18%
win32k.sys : 1877 KB (1.922.048 bytes) / 1562 KB (1.599.488 bytes) => ~ 17%
ntoskrnl.exe : 2253 KB (2.307.072 bytes) / 1902 KB (1.947.136 bytes) => ~ 15.6%
kernel32.dll : 3008 KB (3.080.192 bytes) / 2906 KB (2.975.744 bytes) => ~ 3.4%
* Add an NDK header to define INIT_FUNCTION/INIT_SECTION globally
* Use _declspec(allocate(x)) and _declspec(code_seg(x)) on MSVC versions that support it
* Use INIT_FUNCTION on functions only and INIT_SECTION on data only (required by MSVC)
* Place INIT_FUNCTION before the return type (required by MSVC)
* Make sure declarations and implementations share the same modifiers (required by MSVC)
* Add a global linker option to suppress warnings about defined but unused INIT section
* Merge INIT section into .text in freeldr
Purpose:
When doing a PXE BootCD installation, you may be left without networking, usb and a cd drive.
This adds an easy way to include a few or more files to the installation which are then present on the disk after the installation and which does not require any change to ReactOS source code/build script files (and no manual editing of boot/bootdata/packages/reactos.dff.in).
Proposed changes:
Adds a new modules/3rdparty folder which lets the files end up in C:\ReactOS\3rdParty ready for use.
- Fix parsing of the options.
- Only uppercase the file name part and NOT the full path!
And do it in a way GCC-Linux correctly understands, aka.:
*ptr = toupper(*ptr); ++ptr;
but NOT!:
*ptr++ = toupper(*ptr);
(that last one worked on GCC-Win and MSVC).
[CMAKE] Let's keep SETUPREG.HIV and BCD hive file names in uppercase
(use the '-u' switch) while keeping the other ones in lowercase.
Should definitively fix GCCLin builder!
- Add support for '/' switch characters.
- Add '-?' switch.
TEMPORARY:
- Add a '-u' switch to generate hive file names in uppercase (by default
we keep these in lowercase). Should help in fixing GCCLin builder.
[CMAKE] Fix expected file name case. Should help in fixing GCCLin builder.
This commit is needed for building a single bootcd registry hive. It will also enable 1-st stage setup to have a proper registry present as done on Windows.
CORE-13347
[CMAKE]
Note that the mkhive commands should really depend on the generated UTF16 INF files since the latter are those that are actually used as input for mkhive.
Otherwise, the mkhive calls & the UTF16 INF file conversion is not serialized and we can generate "corrupted" hives due to the fact that mkhive is using
INF files that are in the process of being (and therefore, only partially) generated.
svn path=/branches/setup_improvements/; revision=74741
svn path=/branches/setup_improvements/; revision=74749
* Remove unused cmake modules - Both are unedited versions of modules provided by cmake itself
* Remove Compiler/GNU.cmake - Only chang was various _INIT flags, which are handled
via CMAKE_USER_MAKE_RULES_OVERRIDE instead
* Remove Platform/Windows.cmake - There's no clear explination for this file being in reactos
and is simply an old version of the one in cmake
* Remove Platform/Windows-MSVC.cmake - _INIT variable changes moved to overrides-msvc.cmake
Remove /implib from link commands
* Remove CMakeDetermineASMCompiler.cmake - Only change from 3.2 is the addition of a compiler list for the generic ASM dialect, but toolchain files explicitly set a compiler so the list is never used
