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...
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
