Issue 80753 - --enable-dbgutil: Some DLLs link against msvcr71.dll instead of msvcr71d.dll
Summary: --enable-dbgutil: Some DLLs link against msvcr71.dll instead of msvcr71d.dll
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: 680m225
Hardware: All Windows, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-08-16 16:39 UTC by Stephan Bergmann
Modified: 2013-02-07 22:03 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2007-08-16 16:39:17 UTC
At least with the Hamburg setsolar build environment, at least the SRC680m225
wntmsci10 non-pro (i.e., emulating config_office/configure --enable-dbgutil) OOo
build contains some DLLs that link against the non-debug msvcr71.dll (that is
not included in the installation set) instead of the debug mscvr71d.dll (this is
included in the installation set).

[4nt] soinst
[4nt] cd openofficeorg23\program
[4nt] for i in (*.exe *.bin *.dll) do dumpbin /dependents %i

reveals that at least the following files have this problem:


For program/uwinapi.dll, CWS sb71 will solve this problem by consolidating the
use of both LIBCMT and MSVCRTLIB for similar things in the solenv/inc makefile
Comment 1 Stephan Bergmann 2009-11-11 09:38:34 UTC
With DEV300m64 wntmsci12, the problem is still there (now with msvcr90.dll vs.
msvcr90d.dll).  Within a vanilla (Hamburg built, en-US) DEV300m64 wntmsci12
non-pro installation set, searching for *.exe/*.bin/*.dll that depend on
msvcr90.dll (instead of msvcr90d.dll) gives: 3/program/freebl3.dll 3/program/libcurl.dll 3/program/libeay332.dll 3/program/libxml2.dll 3/program/libxmlsec-mscrypto.dll 3/program/libxmlsec.dll 3/program/libxslt.dll 3/program/lpsolve55.dll 3/program/nspr4.dll 3/program/nss3.dll 3/program/nssckbi.dll 3/program/nssdbm3.dll 3/program/nssutil3.dll 3/program/plc4.dll 3/program/plds4.dll 3/program/python.exe 3/program/python26.dll 3/program/smime3.dll 3/program/softokn3.dll 3/program/sqlite3.dll 3/program/ssl3.dll 3/program/ssleay32.dll 3/program/stlport_vc7145.dll

(Also, searching in the corresponding solver bin directory for additional
*.exe/*.bin/*.dll that depend on msvcr90.dll but are not included in the
installation set, but potentially called during the build, gives:


Whether or not those are problematic needs to be discussed.)
Comment 2 Stephan Bergmann 2009-11-11 13:08:22 UTC
See also issue 106809: "A general solution [...] might also be to no longer link
non-pro builds
against the debug versions of the runtime libs."