Bug Hunting Session
Bug 32426 - auto install as much as possible of windows build dependencies
Summary: auto install as much as possible of windows build dependencies
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-15 13:04 UTC by Caolán McNamara
Modified: 2013-11-14 15:18 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
first attempt (5.79 KB, text/plain)
2010-12-15 13:04 UTC, Caolán McNamara
Details
Suggested patch (4.17 KB, patch)
2010-12-22 04:54 UTC, Don't use this account, use tml@iki.fi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Caolán McNamara 2010-12-15 13:04:41 UTC
Created attachment 41155 [details]
first attempt

RE: http://wiki.documentfoundation.org/Easy_Hacks#Simplify_the_download_of_Windows_dependencies

Had the misfortune to try a windows build again today, and its still to painful. 

So, how about the following. Download some of the depends from microsoft.com, run them automatically, and let the end-user agree/disagree to the ones which present EULAs

Clearly needs fleshing out for different vcredist_x86.exe/vcredist_x64.exe for other compilers than the one I happen to have installed.

There's a cloud of confusion around msvcr71, I wonder if we really need this at all actually ? Does anyone know what might be linked against it. I assume if we build with a later version that VS2003 then we don't actually need it ? If so we could put "-a "$CVER" = "M1310" around that bit in the post_download.in and in scp2
Comment 1 Jan Holesovsky 2010-12-20 22:20:26 UTC
This is cool, thank you for that!  Can you please just commit that to master; let's add the other compiler/redist combinations as/when somebody else needs it.  All this is so painful that I usually end up copying the .dlls from other builds I have around...

And - unfortunately - no idea about the msvcr71 :-(  Tor?
Comment 2 Don't use this account, use tml@iki.fi 2010-12-21 01:00:33 UTC
As discussed on IRC, msvcr71.dll is needed by the JRE. (True at least for current JREs, up to 1.6.0_22.) Sun does distribute a copy of msvcr71.dll with the JRE, but unfortunately for a program, like soffice.exe, that "embeds" the JVM, it won't be found using the normal DLL search rules. Caolán pointed to this nice writeup: http://www.duckware.com/tech/java6msvcr71.html for instance. But in LO we sure can't do what that writer recommends, i.e. chdir to the directory where the msvcr71.dll bundled with the JRE is and back, that sounds like a horribly unreliable hack.

We don't use MSVC7 to build any part of LibreOffice. Certainly, for a random developer who wants to build LibreOffice (and thus build an installer for it, even if he has no intent to redistribute it as such, but just for debugging), it is perhaps not clear from where to get msvcr71.dll. But yeah, we could add logic to find it in the JDK, as a JDK is a requirement for a build currently, isn't it?

Another question is then that it is a bit unclear whether various people who happen to build LibreOffice and do want to redistribute it are even allowed to do that. There doesn't seem to be any redistributable package for the MSVC7 runtime. (Unlike for the later MSVC runtimes.)

So, I suggest we drop the requirement of msvcr71.dll in master, and drop it from the installer. Then, in the code that starts the JVM, we add code to explicitly try to load msvcr71.dll from where it should be as bundled with the JRE. Perhaps, to guard against potential future versions of the JRE that are built against a newer MSVC runtime, we could even inspect the import table of jvm.dll and see what MSVC runtime it uses.
Comment 3 Caolán McNamara 2010-12-21 04:24:00 UTC
Oky doky, committed this work so far. 

I prefer Tor's solution for that problematic .dll, hopefully Tor can look after that :-).
Comment 4 Don't use this account, use tml@iki.fi 2010-12-22 04:54:21 UTC
Created attachment 41369 [details]
Suggested patch

This attempts to load the msvcr71.dll that should be present bundled with the JRE. (If not found, then just bail out and let it be loaded automatically from wherever it gets loaded indirectly when the JVM is loaded.)
Comment 5 Caolán McNamara 2010-12-22 05:08:34 UTC
Looks sane, does we know if it works ?
Comment 6 Don't use this account, use tml@iki.fi 2010-12-22 05:13:33 UTC
Yep, at least in the normal case it worked as intended, I stepped through in the debugger. And in an abnormal case, it shouldn't do anyhthing special, thus not be any worse than what currently happens.