Created attachment 41155 [details]
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
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?
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.
Oky doky, committed this work so far.
I prefer Tor's solution for that problematic .dll, hopefully Tor can look after that :-).
Created attachment 41369 [details]
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.)
Looks sane, does we know if it works ?
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.