`libssl` bindings fall back to ancient library version about crystal HOT 5 OPEN

I'd like to keep this issue focused narrowly on the fallback version in the current state of things. It could be relatively easy to gain a small improvement by updating the fallback to a more recent version. That's certainly not a wholesome solution to the overall problem, but it's managable and has a direct benefit.

We should have another discussion about the whole topic of library information. I'm collecting some talking points for that and will open a thread on the forum.

from crystal.

Related: #7244, #11069

from crystal.

I still believe #7245 was the correct solution: get the information from C headers when pkg-config is missing. It would detect the actual version of libressl or openssl and fail when the headers are missing.

We can't guess what version or which of libressl or openssl is installed, and we shouldn't have to.

from crystal.

@ysbaddaden #7245 could be helpful, but it's not a proper solution. The whole problem is more complex and improving autodiscovery only get's us so far.

This issue is about the current fallback solution if autodiscovery of the library version doesn't work. #7245 wouldn't solve this problem because C headers could be missing as well. So we still need a default behaviour when autodiscovery doesn't work.
I don't think you should need C headers for building Crystal bindings just for figuring out the version. If it works, that's fine. But it must not be a requirement.
A solution could be a mechanism for explicitly configuring the library version.

from crystal.

There is no fallback in #7245: compilation will fail if the C headers aren't installed (or reachable).

from crystal.