Skip to content
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

Add method to check with runtime library is loaded #5047

Open
ThadHouse opened this issue Oct 27, 2024 · 7 comments
Open

Add method to check with runtime library is loaded #5047

ThadHouse opened this issue Oct 27, 2024 · 7 comments
Labels
enhancement Something can be improved vNext Breaks binary compatibility

Comments

@ThadHouse
Copy link

ThadHouse commented Oct 27, 2024

The std::mutex constexpr change that breaks on older runtimes has been a nightmare for a lot of users. I'm not here to get into that, I just want to try and get a better way to detect that error. Is there a way to detect at runtime which versions of the msvc runtime dlls are actually loaded? If not, could we get a mechanism to do that in the future. That way we ourselves could check for that incompatibility.

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.

@StephanTLavavej
Copy link
Member

You should be deploying the latest version of the VCRedist with your application, instead of trying to check whether one has already been installed and how outdated it is.

@ThadHouse
Copy link
Author

ThadHouse commented Oct 27, 2024

The issue is we're not the ones shipping an application. We're shipping a library that is loaded from Java through JNI. And older JVMs don't have a new enough runtime. We just want to be able to preemptively print a better error message then a crash, so we can tell our users they need to go get a new JVM.

This would allow us to act much more like Linux does, where the standard library symbols are versioned. So if an update occurs, the new symbols won't exist on older runtimes and the error message is much more sane.

It's plugin scenarios that were really hurt by this change, as they're dependent on the applications they plug into. Applications had an easy enough time updating, but plugins don't have a way to detect the runtime at all, so they're just hoping their application updated.

@StephanTLavavej
Copy link
Member

In this case you should define the escape hatch macro. Sorry, we don't have other mechanisms for this scenario when you're dealing with a hosting application that's making it difficult for the program as a whole to obey our documented binary compatibility requirements.

In the future, we might consider exercising this requirement more frequently, and failing in a more noisy way (e.g. if we added a dllexport every update, and tried to use it, that would likely emit a clear message about an API not being found). However, we're not likely to do that in the remainder of the "v14" (VS 2015+) binary-compatible release series.

@ThadHouse
Copy link
Author

ThadHouse commented Oct 27, 2024

Sounds good. We'll just make sure to document what the failures look like. Our setup with how spread things are makes it difficult to guarantee everyone we depend on sets the escape hatch.

Some way of being more noisy would be amazing. Noisy errors that say your program is doing something bad is exponentially better then crashing.

On a side note, what is the compatibility requirements between individual libraries in the runtime? The reason I'm asking is most JDKs only ship msvcp140.dll, and not the _1 and _2 libraries. So assuming you have a system wide runtime installed, the msvcp140.dll will be picked up from the app, but the _1 and _2 libraries will be picked up from the system wide runtime. What happens if these versions don't match?

@Osyotr
Copy link

Osyotr commented Oct 30, 2024

We're shipping a library that is loaded from Java through JNI. And older JVMs don't have a new enough runtime.

Is linking msvc runtime statically an option? To me it looks like an obvious solution to the problem.

@ThadHouse
Copy link
Author

We're shipping a library that is loaded from Java through JNI. And older JVMs don't have a new enough runtime.

Is linking msvc runtime statically an option? To me it looks like an obvious solution to the problem.

It's not, as we ship multiple dlls that need to share standard library objects across the DLL boundary.

@StephanTLavavej StephanTLavavej added enhancement Something can be improved vNext Breaks binary compatibility labels Oct 30, 2024
@StephanTLavavej
Copy link
Member

On a side note, what is the compatibility requirements between individual libraries in the runtime? The reason I'm asking is most JDKs only ship msvcp140.dll, and not the _1 and _2 libraries. So assuming you have a system wide runtime installed, the msvcp140.dll will be picked up from the app, but the _1 and _2 libraries will be picked up from the system wide runtime. What happens if these versions don't match?

We don't test or support that scenario, but there aren't strong dependencies between the main and satellite DLLs at this time, so you're very likely to get away with mismatch there.

While we aren't planning to make any changes for the current release series, I'm going to label this issue as enhancement Something can be improved vNext Breaks binary compatibility as a reminder that when we can break ABI, at a minimum we should add an export that lets us query the STL DLL's version, and possibly add exports in every release that we consume, so as to prevent this ecosystem problem from accumulating again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved vNext Breaks binary compatibility
Projects
None yet
Development

No branches or pull requests

3 participants