New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's link the dynamic VC runtime again #9443

Closed
alespergl opened this Issue May 12, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@alespergl
Contributor

alespergl commented May 12, 2017

#5602 switched to static Visual C++ runtime, but there are issues with that:

  • The runtime is unnecessarily duplicated in node.dll and electron.exe.
  • #7281 reports that Electron-wide native exception handling is broken because exception handlers are applied per runtime instance.
  • node.dll exports some symbols of the runtime, and when a native node module uses the dynamic runtime, it can mistakenly bind to those symbols instead of the ones from msvcp140 and friends. This ends up causing crashes when an object is initialized using one instance of the runtime and destroyed using the other instance.
  • Wrapper functions had to be introduced to make even Electron itself run correctly with the statically linked runtime.

The reason why it was decided to link the runtime statically was to "remove" a dependency on the Universal CRT (UCRT). That argument is weak, because the dependency is not actually removed, but merely UCRT is also statically linked and duplicated. Therefore the real argument is to not have to redistribute the UCRT binaries for non-updated Windows 7 systems and that is not a strong enough reason to justify the above problems.

So I am suggesting we move back to linking the VC runtime dynamically and redistribute it together with UCRT. I will prepare and submit a PR in the coming days.

@alespergl

This comment has been minimized.

Contributor

alespergl commented May 15, 2017

@computerquip-streamlabs

This comment has been minimized.

computerquip-streamlabs commented Jun 11, 2017

node.dll exports some symbols of the runtime, and when a native node module uses the dynamic runtime, it can mistakenly bind to those symbols instead of the ones from msvcp140 and friends. This ends up causing crashes when an object is initialized using one instance of the runtime and destroyed using the other instance.

This is actually blocking my current use case. If there's anything I can do to speed up a fix for this, that would be great. I can build myself but it complicates application distribution heavily (plus I'm not sure how to repackage the electron build since documentation on that seems to have been left out).

I can also statically link against the VC++ runtime but that gives me almost no benefit while adding to my distribution size. Not cool. ;(

@alespergl

This comment has been minimized.

Contributor

alespergl commented Jun 23, 2017

Fixed, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment