Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities.
Um, we’re talking about undefined behavior here. That creates potential RCE vulnerabilities—the most severe kind of vulnerability. So no, a botched dynamically-linked library update can easily create a vulnerability worse than the one it’s meant to fix.
Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages.
Shared libraries are shared among processes, not programming languages.
Not without suitable glue code, you can’t. If you want to use a native library with Java or Node.js, you need to wrap it in a JNI or N-API wrapper. The wrapper must be dynamically linked, but the native library can be statically linked with the wrapper. My current project does just that, in fact.
There is one exception I know of. The Java library JNA dynamically links native libraries into a Java program and generates the necessary glue at run time.
Um, we’re talking about undefined behavior here. That creates potential RCE vulnerabilities—the most severe kind of vulnerability. So no, a botched dynamically-linked library update can easily create a vulnerability worse than the one it’s meant to fix.
Shared libraries are shared among processes, not programming languages.
You still can use them in any programming language
Not without suitable glue code, you can’t. If you want to use a native library with Java or Node.js, you need to wrap it in a JNI or N-API wrapper. The wrapper must be dynamically linked, but the native library can be statically linked with the wrapper. My current project does just that, in fact.
There is one exception I know of. The Java library JNA dynamically links native libraries into a Java program and generates the necessary glue at run time.