Apache OpenOffice (AOO) Bugzilla – Issue 127731
AOO fails to open ODBC manager
Last modified: 2023-10-03 15:36:21 UTC
Created attachment 86363 [details] Error when trying to open ODBC administrator from within AOO This is a regression on Windows (AOO 4.1.5 works as expected). Steps to reproduce: - File | New | Database - Choose Connect to existing database - Choose ODBC as type - Click Next >> - Click Browse - Click Organize... Result: ODBC administrator can not be opened. Sometimes I get an error message, sometimes it fails to load silently. Expected behavior: On Windows32 the ODBC administrator (odbcad32.exe) should be opened. (On future Windows64 builds odbcad64.exe should be opened instead)
Actually AOO tries to open its own odbcconfig.exe which is only a "wrapper" to launch the ODBC manager from Windows. See (lines 364 ff.): https://svn.apache.org/repos/asf/openoffice/trunk/main/dbaccess/source/ui/dlg/odbcconfig.cxx and: https://svn.apache.org/repos/asf/openoffice/trunk/main/dbaccess/win32/source/odbcconfig/odbcconfig.cxx
Changes seem to be in Revision 1755455: https://svn.apache.org/viewvc?limit_changes=0&view=revision&revision=1755455 "Merge branches/gbuild-reintegration to trunk."
Hi Matthias, are you the only one with this error? Have you tried to fix this like suggested here: https://errortools.com/windows/fix-runtime-error-r6034/
Does this happen on a product build or non-product build? Please post all your ./configure flags. Also please post the output of: DUMPBIN /IMPORTS C:\path\to\odbcconfig.exe (you might need to run MSVC's VCVARS.BAT first)
(In reply to Peter from comment #3) > Hi Matthias, > > are you the only one with this error? > Have you tried to fix this like suggested here: > > https://errortools.com/windows/fix-runtime-error-r6034/ Hi Peter, Damjan could reproduce it, see also i127732.
(In reply to damjan from comment #4) > Does this happen on a product build or non-product build? > > Please post all your ./configure flags. > > Also please post the output of: > > DUMPBIN /IMPORTS C:\path\to\odbcconfig.exe > > (you might need to run MSVC's VCVARS.BAT first) This happens with trunk and 42x so I wouldn't call it a production build. But the configure is almost identical to a release version: http://svn.apache.org/repos/asf/openoffice/devtools/build-scripts/4.2.0-Dev1/wntmsci/ReadMe.txt dumpbin.exe gives me an error, see issue 127732.
Looking at the log from our Windows buildbot: https://ci.apache.org/projects/openoffice/buildlogs/win/main/dbaccess/wntmsci12.pro/misc/logs/prj.txt esp. this line seems wrong: R=/cygdrive/e/slave14/aoo-win7/build && S=$R/main && O=$S/solver/450/wntmsci12.pro && W=$O/workdir && mkdir -p $O/bin/ && /usr/bin/cp --remove-destination -R -P --force --preserve=timestamps $W/LinkTarget/Executable/odbcconfig.exe $O/bin/odbcconfig.exe && mkdir -p $O/bin/ && /usr/bin/cp --remove-destination -R -P --force --preserve=timestamps $W/LinkTarget/Executable//odbcconfig.exe.manifest $O/bin/odbcconfig.exe.manifest Where does the double slash (//) come from?
We should get hold of the odbcconfig.exe binary from before and after the commit that broke it, and examine its layout (imports, sections, symbols, etc.). There must be some difference there.
Funny fact: After building odbcconfig.exe in main\solver\420\wntmsci12.pro\bin starts without problem and shows the expected dialog.
Double clicking on "OpenOffice 4\program\odbcconfig.exe" with different AOO versions: Some branch I called "AOO41X-merge-base-2014-02-25": Works, opens up successfully. 2ed47956e3ec22116d5164494008afeac3f699a1 from 2015-08-29: Works, opens up successfully. Some version I called 127624: +----------------------------------------------------+ | odbcconfig.exe - Unable To Locate Component | +----------------------------------------------------+ | This application has failed to start because | | MSVCRT90.DLL was not found. Re-installing the | | application may fix the problem. | +----------------------------------------------------+ A recent trunk: +----------------------------------------------------+ | odbcconfig.exe - Unable To Locate Component | +----------------------------------------------------+ | This application has failed to start because | | MSVCRT90.DLL was not found. Re-installing the | | application may fix the problem. | +----------------------------------------------------+ Comparing the odbcconfig.exe executables from these versions: * All of them use imports from MSVCR90.DLL. * MSVCRT90.DLL is only found in: c:/WINDOWS/WinSxS/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll c:/WINDOWS/WinSxS/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43/msvcr90.dll * To load DLLs from this side-by-side assembly ("WinSxS"), you probably need a manifest/assembly/whatever it's called. * The odbcconfig.exe files that work, when opened in the "HT editor" disassembler (https://sourceforge.net/projects/hte/) have a "pe/resources" section with a single resource, which is an XML file <assembly ...> which specifies the dependency on "Microsoft.VC90.CRT". * The odbcconfig.exe files that don't work, when opened in the "HT editor", HAVE NO "pe/resources" SECTION!!! By the looks of it, most other executables we ship (uno.exe, regcomp.exe), also lack the "pe/resources" section and give them same error. (The main executable, soffice.exe, always has a "pe/resources" section and always works.) Is it just me, or this the real problem here? Many executables, when built with gbuild, don't contain a manifest to load MSVCRT90.DLL, and thus cannot be run on Windows?
(In reply to Matthias Seidel from comment #9) > Funny fact: > > After building odbcconfig.exe in > > main\solver\420\wntmsci12.pro\bin > > starts without problem and shows the expected dialog. If my theory is right, it would explain this as well. Linking an "executable.exe" file, also generates an "executable.manifest" file. dmake's build scripts have a step where they link the executable.manifest into the executable.exe, eg. for uno.exe: ---snip--- linking ../../wntmsci12/bin/uno.exe.manifest ... if [ -f ../../wntmsci12/bin/uno.exe.manifest ] ; then mt.exe -manifest ../../wntmsci12/bin/uno.exe.manifest -outputresource:../../wntmsci12/bin/uno.exe\;1 ; fi ---snip--- gbuild's build scripts, however, do not use mt.exe, and instead copy the manifest to the ${OUTDIR}/bin directory. From there, the manifest is NOT PACKAGED (into instsetoo_native), resulting in no manifest in the release binaries. When a module is ported from dmake to gbuild, and you run eg. uno.exe or Matthias's odbcconfig.exe from {OUTDIR}/bin, it works because the uno.exe.manifest or odbcconfig.exe.manifest is also in that directory. However in the release binaries in instsetoo_native, it won't work, because the manifests aren't packaged. If you copy uno.exe.manifest into the instsetoo_native directory where uno.exe is, and try running uno.exe, it starts working. Rename uno.exe.manifest to odbcconfig.exe.manifest, and odbcconfig.exe starts working. Either we need to: 1. Link the manifest into the executable as a resource, and stop delivering it into ${OUTDIR}, like dmake did. 2. Package the manifests along with their executables. I think option 1 is clearer. It's unclear why gbuild tried to move to option 2.
Looking at https://bz.apache.org/ooo/show_bug.cgi?id=127731#c7 I still think a path with double slashes cannot be right. I already fixed one or two occasions where a path was combined from two parts, the first ending with a slash, the second starting with a slash.
(In reply to Matthias Seidel from comment #12) > Looking at > > https://bz.apache.org/ooo/show_bug.cgi?id=127731#c7 > > I still think a path with double slashes cannot be right. > > I already fixed one or two occasions where a path was combined from two > parts, the first ending with a slash, the second starting with a slash. I haven't been able to find where that comes from, but who cares. In this case, that doesn't matter, the double slashes work, the file is successfully delivered, but then later breaks because it isn't packaged. With the fix I am testing now, we wouldn't even need to deliver the .manifest file any more, because it get embedded into the binary instead, just like with dmake.
It works, that MSVCRT90.DLL error is gone, for all gbuild executables including python.exe, uno.exe, etc., not just odbcconfig.exe. Resolving FIXED, thank you for your bug report :). commit 104751b68faf29eef4f137251f7b9ecd22ed8074 (HEAD -> trunk, origin/trunk, origin/HEAD, 127731-odbcconfig) Author: Damjan Jovanovic Date: Sun Oct 1 09:48:00 2023 +0200 For gbuild, when linking a binary on Windows produces a .manifest file, embed this manifest into the binary like dmake did. Unfortunately our old version of LINK.EXE doesn't have the /MANIFEST:EMBED option, so the manifest has to be be embedded by calling MT.EXE in a separate step. Also, stop delivering the .manifest files to ${OUTDIR} now. Patch by: me Fixes: #127731 - AOO fails to open ODBC manager
Thank YOU for the fix! Confirmed FIXED with latest trunk on Windows 10. Cherry-picked to AOO42X with: https://github.com/apache/openoffice/commit/bc01e889163b95849e5617a241242df2f94536ec
*** Issue 128094 has been marked as a duplicate of this issue. ***