On Sun, Jan 26, 2025 at 12:17 PM Matthias Seidel <matthias.sei...@hamburg.de> wrote:
> Hi Damjan, > > Am 26.01.25 um 04:23 schrieb Damjan Jovanovic: > ... > > The code that prints that error is at > > > http://opengrok.openoffice.org/xref/trunk/main/solenv/bin/modules/installer/epmfile.pm?r=49cc8443#780 > > . > > > > Try to see what the value of your EPM environment variable is. Also > > config.log might help. > The question is, why use epm at all? It is a Linux packager(?) and I > built all Windows 32-bit releases in the past years without it. > > Tracing backwards from find_epm_on_system() using OpenGrok, I see that it's called from line 956 of MakeNonWindowsBuild() in file main/solenv/bin/ make_installer.pl. That is in turn called from line 2261 in the same file, if the "iswindowsbuild" variable is 0. The make_installer.pl file is itself called from line 253 of main/instsetoo_native/util/makefile.mk. But where is iswindowsbuild set? Apparently only in main/solenv/bin/modules/installer/parameter.pl: 279 if ( $installer::globals::compiler =~ /wnt(msc|gcc)i/ ) 280 { 281 $installer::globals::iswindowsbuild = 1; 282 } That regular expression on line 279 probably needs to be changed to /wnt(msc|gcc)[ix]/. Can you please try that, and commit it if it works? I've been testing and debugging that UNO bridge in main/bridges/source/cpp_uno/msvc_win64_x86-64. It's not a lot of code, but progress has been slow and difficult. Cygwin's gdb is useless and produces wrong stack traces, either by printing wrong info or corrupting the environment somehow. I've had to hack that code by adding 0xCC opcodes (for "INT 3") in various places, and then examine the raw registers, stack and disassembled code. I've managed to fix some of the problems, I increased the snippet size which got rid of the assertion error crashes, fixed a bad type_info layout in the RTTI, and eventually even found and fixed some bad machine code opcodes I must have mistyped in codeSnippet() when I first entered them and which were corrupting the stack. This finally gets some of the UNO bridge tests in main/testtools to run successfully, and 18 C++ to UNO functions get called (and presumably work and return successfully), before it crashes elsewhere, in a UNO to C++ call. Also I used to get 2 crashes during the main/testtools test, now I get only 1 crash. So we are slowly getting there ;-). Regards Damjan
