Closed Bug 1376051 Opened 7 years ago Closed 8 months ago

Update vcruntime140.dll to version 14.00.24215.1

Categories

(Firefox Build System :: General, enhancement)

Product:
Firefox Build System
Component:
General
Version:
55 Branch
Platform:
All
Windows
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1783888

People

(Reporter: BesTo, Unassigned)

References

Details

Update vcruntime140.dll from version 14.00.24200.0 to version 14.00.24215.1.
This version is included in "Microsoft Visual C++ 2015 Redistributable Update 3" and is dated 2016-08-25.
Ryan, is there anything to be done here?
Flags: needinfo?(ryanvm)
Can a update of vcruntime140.dll maybe help with crashes like this one:
https://crash-stats.mozilla.com/report/index/71490685-48dc-45df-b959-571360170625
302 gps
Flags: needinfo?(ryanvm) → needinfo?(gps)
What's about updating to VS2017 and vcruntime140.dll v14.10.xxxx?
Component: General → Build Config
Product: Firefox → Core
vcruntime140.dll is version 14.0.24210.0 in our current vs2015u3.zip archives used by automation. I'm not sure what release this corresponds to. But it shouldn't be difficult to roll a new archive with the latest version.

VS2017 is a bigger ordeal and is tracked elsewhere. It likely won't happen until Firefox 58 at the earliest.
Flags: needinfo?(gps)
I'll produce a new toolchain archive.
Assignee: nobody → gps
Status: NEW → ASSIGNED
The latest version of the VS2015 Redistributable is 14.0.24212. However, that version isn't getting installed by the Visual Studio installer.

It should be safe to take the latest version being offered for download by Microsoft. But I'd really like to see a changelog so we know what we're dealing with.
I'm updating Visual Studio in the VM I use to build the toolchains used by automation (as opposed to my local machine, which I used for comment 7) and I noticed a reference to 14.0.24212 scroll by. So either the toolchain used by this VM will use a modern version or we may have a bug in our script to build the toolchain archive. Either way, I should have patches in an hour or two.
The reinstall of VS2015 in the VM produced the same result: both installs place version 14.0.24210.0 into %VCINSTALLDIR%\VC\redist\{x86,x64}.

However, c:\Windows does have the latest version (14.0.24215.1).

I'm hesitant to pull a different version into the toolchain archive and overwrite what Visual Studio itself installs (and possibly uses).

Looking at the build system code, we explicitly define the location of the runtime by pointing WIN32_REDIST_DIR into the toolchain archive as part of in-tree mozconfigs. So, a fix for this is to package the runtime into a separate directory in the toolchain archive and update references to point to it. This is a bit more work than I was expecting. But it shouldn't be too bad.
So, uh, I'm not sure the best way to package the vc++ runtime. The standalone .exe installers don't allow you to install to a custom location. The exe expands to a bunch of randomly named files. The best resource I could find for extracting files is http://www.applepie.se/extract-msi-from-visual-c-2012-redistributable, which is scary and doesn't appear very robust.

Backing up a bit, what we need to do is produce a standalone archive containing the files so we can upload it to tooltool and extract it as part of the build. That can't be an exe because we can't run system-wide installers as part of the build. I figured it would be trivial to extract files from the standalone installers and repackage them in a zip file or something. But that is not the case. I want whatever the process is for producing the archive to be reproducible so when the next runtime release comes out we can upgrade with minimal effort.

Anyway, this has turned into a bit of a rabbit hole, so unassigning myself. I have a feeling someone has solved this problem before, I'm just not finding it on the Internets. And unless we know the updated runtime will actually improve Firefox in a meaningful way, I can't justify the effort to figure this out at this time.
Assignee: gps → nobody
Status: ASSIGNED → NEW
(In reply to Gregory Szorc [:gps] from comment #10)
> I have a feeling someone has solved this problem before, I'm just not
> finding it on the Internets.

Do you search for this?
https://superuser.com/questions/307678/how-to-extract-files-from-msi-package
Yes. The files extracted from the exe have 2 and 3 character filenames with no extension. I suspect Microsoft has obfuscated the contents of the installer to prevent people from doing what I want to do :)
Why don't Fx have the re-distributable as a requirement?
The installer can install it and the people that use the ZIP should install it self...
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #14)
> Why don't Fx have the re-distributable as a requirement?
> The installer can install it and the people that use the ZIP should install
> it self...

I'm not sure. rstrong?

I suspect it may have to do with "because distributing the redistributable installer will bloat the Firefox installer download size." https://msdn.microsoft.com/en-us/library/ms235299.aspx for more on the topic.
Flags: needinfo?(robert.strong.bugs)
Because it wasn't necessary to bundle the redistributable installer in the past. As for bloat, that is typically decided outside of the installer and the installer just ships the files it is given.
Flags: needinfo?(robert.strong.bugs)
With all the files that are now included in the 64-bit-version, IMHO it would be the right way to use at least for this version the redistributable.
My 2 cents are that if that only a subset of the files from the redistributable are needed then to keep the size down it would be best to continue to ship it as has been done in the past and just update the files as has been done in the past. This also keeps the complexity as part of the build process vs. adding complexity to the client process.
Product: Core → Firefox Build System
Severity: normal → S3

Firefox 51 was already using 14.00.24210.0 tbh.
Anyhow, even that was eventually fixed with the switch to VS 2017 in FF58.

See bug 1783888 if any now.

Duping forward because it doesn't seem useful to keep this open separately at this point.

Status: NEW → RESOLVED
Closed: 8 months ago
Duplicate of bug: 1783888
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.