> Well you build OpenSSL as a static library, and you use that...
I mean yes that's what I do but see my comment, I was asking specifically about dynamic linking mentioned by the parent (OpenSSL is definitely a "core library")
> I think there is fundamentally no way (and that's by definition) to support two explicitly incompatible versions in the same build.
Yes, that's my point - in the end static linking is the only thing that will work reliably when you have to ship across an array of distros even for core libraries... The only exceptions in my mind is libgl & other drivers
I strongly believe that developers should not ship across an array of distros. First because you probably don't test on them all.
Really, that's the job of the distro/package maintainers. As a developer, you provide the sources of your project. If people want to use it on their respective distro, they write and maintain a package for it, or ask their distro maintainers to do it. That is the whole point of the distro!
Well, I completely disagree. I have a fair amount of users on a wide array of distro who are non-technical - just users, they wouldn't know how to compile something let alone write a distro package. They still deserve to be able to use the software they want without having to change OS.
> or ask their distro maintainers to do it.
This only works if you're using a rolling-release distro. You can't get new packages in the repos of Ubuntu 20.04, Suse Leap, Fedora 30 or Debian Bullseye.
I mean yes that's what I do but see my comment, I was asking specifically about dynamic linking mentioned by the parent (OpenSSL is definitely a "core library")
> I think there is fundamentally no way (and that's by definition) to support two explicitly incompatible versions in the same build.
Yes, that's my point - in the end static linking is the only thing that will work reliably when you have to ship across an array of distros even for core libraries... The only exceptions in my mind is libgl & other drivers