by hand!
Motivation is to fix relocations during 2nd/3rd stage of the kind:
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\System32\spool\PRTPROCS\W32X86\winprint.dll (10000000-1000A000 -> 003D0000)
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\system32\localmon.dll
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name beepmidi.dll (7A140000-7A147000 -> 00BF0000)
(C:\047rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\browseui.dll
Motivation is to fix the following warnings at configure-time for *MSVC x86 dbg* :
-- shsvcs has no base address
-- libtirpc has no base address
-- acgenral has no base address
-- nfs41_np has no base address
-- shellbtrfs has no base address
-- ntdll_vista has no base address
-- redirtest1 has no base address
-- redirtest2 has no base address
-- localspl_apitest.dll has no base address
-- localmon has no base address
-- winprint 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.
This updates the GCC baseaddress_msvc.cmake
to the state we do use in releases/0.4.10 to date
leaving out the components that do not exist in releases/0.4.7 yet,
And additionally preserves the addresses for the 3 fusion dlls,
which our script currently cannot handle yet.
Therefore manually respecting the differences for:
set(baseaddress_localspl_apitest.dll
set(baseaddress_fusion
set(baseaddress_fusion_1_1
set(baseaddress_fusion_2_0
pick part of 0.4.10-dev-312-g a3ddb8a4c2 to harmonize the
inconsistency in the base-address-files regarding winspool.
Since an ancient winspool-name-change
the baseaddress*.cmake files do reference the winspool module in an inconsistent style:
- 'baseaddress_winspool' in baseaddress.cmake 'was already' / 'is still' ok without
the 'drv' in the older branches (unlike 0.4.10-dev-311)
- 'baseaddress_winspool.drv' in baseaddress_dwarf.cmake
- 'baseaddress_winspool.drv' in baseaddress_msvc.cmake
And therefore only GCC did properly set a base address, but MSVC failed at that.
No warnings afterwards anymore about 'winspool has no base address' during configure.
