Description
a follow-up of CORE-14831.
reported against 0.4.15-dev-6961-g8860dc5 (where we just recently ran the Python script to refresh the modules base-addresses, just a few days ago).
I just reconfigured my clean workspace (had no output folder before that) in RosBEWin2.2.2 GCC8.4.0 by:
configure -DENABLE_ROSTESTS=1 -DENABLE_ROSAPPS=1
|
and that proves that we do lack the base-addresses for vfd and notifyhook now.
The Python script seems to still be wrong in that regard.
0.4.15-dev-6961-g8860dc5 is affected for GCC8.4.0dbg baseaddr.PNG
0.4.14-release-97-g1dbf277 performs fine for both: gcc and msvc dbg
0.4.13-release-163-gea05d36 performs fine for both: gcc and msvc dbg
0.4.12-release-192-g65ea40f performs fine for both: gcc and msvc dbg
0.4.11-release-202-gcfb4e08 performs fine for both: gcc and msvc dbg
0.4.10-release-219-g5b13538 performs fine for both: gcc and msvc dbg
0.4.9-release-230-g7c7b7e3 performs fine for both: gcc and msvc dbg
0.4.8-release-238-gb098b6e performs fine for both: gcc and msvc dbg
0.4.7-release-270-gac63055 performs fine for both: gcc and msvc dbg
But the releases were handgroomed in that regard, does not necessarily imply that the script would have become worse since then. I cannot say.
Attachments
Issue Links
- relates to
-
CORE-14831 CORE-11382 addendum: fix 3+1 remaining "XYZ has no base address", The python script for regenerating the GCC base addresses does not properly cover fusion, fusion1_1, fusion2_0, localspl_apitest.dll
- Resolved