by hand!
Motivation is to fix relocations during 2nd stage of the kind:
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\System32\browseui.dll (7A0B0000-7A17D000 -> 00C40000)
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\beepmidi.dll
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1311) LDR: LdrpMapDll Relocating Image Name stdole32.tlb (10000000-10004000 -> 00D10000)
(C:\049rls\reactos\dll\ntdll\ldr\ldrutils.c:1350) Overlapping DLL: C:\ReactOS\System32\stdole2.tlb
Motivation is to fix the following warnings at configure-time for *MSVC x86 dbg* :
-- shsvcs has no base address
-- dxtn 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
-- zipfldr has no base address
-- ntdll_vista has no base address
-- verifier has no base address
-- redirtest1 has no base address
-- redirtest2 has no base address
-- localspl_apitest.dll has no base address
-- custom has no base address
-- vfd 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 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.9 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.
No false hopes though: The baseaddress-files do still remain a big mess afterwards,
especially in releases/0.4.9 for GCC dbg where we not only have the 'usual incomplete files'
but also still have and always had a lot of relocations between ros components at runtime
because some ros modules do overlap since some Wine-sync during 0.4.9-dev'ing, which
increased the binary sizes. But I just wanted to focus on the avoidable winspool-detail here for now.
Might deal with the other stuff later.
