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
Status: CONFIRMED
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:
URL:
Keywords:
Depends on:
Blocks:
 
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: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

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
\\jumbo2\ship\install\wntmsci10\OpenOffice\msi\SRC680_m225_native_packed-1_en-US.9196\openofficeorg23.msi
[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:

program/icuin36.dll
program/icuuc36.dll
program/libcurl.dll
program/libxml2.dll
program/libxslt.dll
program/nsldap32v50.dll
program/uwinapi.dll

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
framework.
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:

OpenOffice.org 3/program/freebl3.dll
OpenOffice.org 3/program/libcurl.dll
OpenOffice.org 3/program/libeay332.dll
OpenOffice.org 3/program/libxml2.dll
OpenOffice.org 3/program/libxmlsec-mscrypto.dll
OpenOffice.org 3/program/libxmlsec.dll
OpenOffice.org 3/program/libxslt.dll
OpenOffice.org 3/program/lpsolve55.dll
OpenOffice.org 3/program/nspr4.dll
OpenOffice.org 3/program/nss3.dll
OpenOffice.org 3/program/nssckbi.dll
OpenOffice.org 3/program/nssdbm3.dll
OpenOffice.org 3/program/nssutil3.dll
OpenOffice.org 3/program/plc4.dll
OpenOffice.org 3/program/plds4.dll
OpenOffice.org 3/program/python.exe
OpenOffice.org 3/program/python26.dll
OpenOffice.org 3/program/smime3.dll
OpenOffice.org 3/program/softokn3.dll
OpenOffice.org 3/program/sqlite3.dll
OpenOffice.org 3/program/ssl3.dll
OpenOffice.org 3/program/ssleay32.dll
OpenOffice.org 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:

$SOLARBINDIR/graphite.dll
$SOLARBINDIR/libexslt.dll
$SOLARBINDIR/xmllint.exe
$SOLARBINDIR/xsltproc.exe

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."