Stephan Bergmann wrote:
Stephan Bergmann wrote:
Stephan Bergmann wrote:
[...]
The interesting thing, however, is that if I re-build this test
scenario from scratch, with a main.exe and first.dll and second.dll
(corresponding to soffice.bin, soffice.dll, sal3.dll, resp.) built
"by hand" (without many of the switches used in the OOo build
env.)---then it works! I then do not even need the MS runtime libs
in the C:\TEST\sub directory, the process starts happily with the
runtime libs just in the C:\TEST directory next to the executable,
and the re-thrown exception is caught.
So, maybe there is still hope, if we can identify the critical
difference in the build environments for the two scenarios, and adapt
the OOo build env. correspondingly...
The magic difference appears to be the way the Windows SDK mt tool is
called to include XXX.dll.manifest in XXX.dll itself. The OOo build
environment uses a resource_id of 2 (i.e.,
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, cf. WinUser.h in the Windows
SDK), while I used the default (CREATEPROCESS_MANIFEST_RESOURCE_ID,
defined as 1). There appears to be no particular reason to use 2 in
solenv/inc/tg_shl.mk:1.98 and following revisions (and
solenv/inc/_tg_shl.mk generated from it), so I am now doing a
DEV300m11 wntmsci12.pro OOo built with those places changed to the
default, hoping that the resulting application will work fine.
(However, the sad truth is that such a build takes on the magnitude of
days rather than hours for me, so it will be some time before we know
for sure...)
...and the freshly built OOo indeed appears to work fine!
However, one detail still puzzles me: During the OOo build, the gperf
tool is called. In the Sun Hamburg build environment, it is available
as a pre-built executable (r:\btw\DEV300\gperf.exe) that appears to be
built with the .Net 2005 compiler (it links against msvcr80.dll) but
also, for whatever reason, links against OOo's own sal3.dll. However, a
copy of the sal3.dll is not placed next to gperf.exe in r:\btw\DEV300,
so, due to the PATH settings in the build environment, the sal3.dll
produced during the OOo build itself is used (the one in the solver, at
wntmsci12.pro\bin\sal3.dll). Bad as that may be, it appears to have
always worked fine (not too much of a surprise, given that sal has a
stable interface). But with my changes (sal3.dll containing
sal3.dll.manifest with resource_id 1 instead of 2), the calls to gperf
during the OOo build now fail:
<quote>
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: D:\shared\solar\r\btw\DEV300\gperf.exe
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contatct the application's support team for more information.
</quote>
followed by
<quote>
gperf.exe - Application Error
The application failed to initialize properly (0xc0000142). Click on OK
to terminate the application.
</quote>
So I thought maybe the redistributable runtime files (msvcr90.dll etc.)
were missing from the location where sal3.dll is located, so I copied
them there (solver's wntmsci12.pro\bin), but the failure remained.
Does that mean that my change would mean that the URE libraries now only
work in an executable compiled with the exact same Microsoft compiler
version as the URE libraries themselves? Maybe someone else can help
shed some light on this...
As nobody was able to shed enough light on this issue to clear the fog,
it appears to be too brittle an approach to switch from
ISOLATIONAWARE_MANIFEST_RESOURCE_ID to
CREATEPROCESS_MANIFEST_RESOURCE_ID and wait for all sorts of unexpected
anomalies to pop up over time.
The next worst thing is to remove the MS runtime files from the three
OOo layers and instead install them into the system during OOo
installation, so we will now go down that route (and see where we get).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
