Hi Damjan,

Am 27.01.25 um 07:50 schrieb Damjan Jovanovic:
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?

It works!

It has built the installer! :-D

Testing further...

Regards,

   Matthias


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

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur

Reply via email to