OpenSSL: New version 3.0.12

[eschnett]

No description provided.

[giordano]

We were just discussing right now on slack that the x86_64 windows build has something very weird: the library is called libcrypto-3-x64.dll, instead of something simpler like libcrypto.dll like on all other platforms. It'd be great to understand why the heck this is happening, and normalise the basename of the library, otherwise all downstream packages will have a hard time to link to it.

[giordano]

This is also very clear from

Yggdrasil/O/OpenSSL/[email protected]/build_tarballs.jl

Lines 16 to 17 in ec6dc9e

	LibraryProduct(["libcrypto", "libcrypto-3", "libcrypto-3-x64"], :libcrypto),
	LibraryProduct(["libssl", "libssl-3", "libssl-3-x64"], :libssl),

[eschnett]

The respective paragraphs in INSTALL.md describe this, as if this was intentional:

Shared libraries are named a little differently on different platforms.
One way or another, they all have the major OpenSSL version number as
part of the file name, i.e.  for OpenSSL 1.1.x, `1.1` is somehow part of
the name.

On most POSIX platforms, shared libraries are named `libcrypto.so.1.1`
and `libssl.so.1.1`.

on Cygwin, shared libraries are named `cygcrypto-1.1.dll` and `cygssl-1.1.dll`
with import libraries `libcrypto.dll.a` and `libssl.dll.a`.

(The following paragraph explains the x64 suffix as well.)

I don't know what an "import library" is on Windows, but it might be that this is the library that is used when building a library/executable, and which points to the shared library that will be used at run time, which is the one with the complicated name. If that is so, then the downstream packages do not need to handle this manually.

[giordano]

The problem was that the OpenSSL import libraries for x86_64 mingw are in lib64/, instead of lib/ like any other package, so the trick for Cyrus SASL was to manually set LDFLAGS="-L${prefix}/lib64":

Yggdrasil/C/CyrusSASL/build_tarballs.jl

Lines 47 to 48 in 5a494a9

	# On x86_64 mingw32 the import libraries of OpenSSL are in `lib64/`.
	export LDFLAGS="-L${prefix}/lib64"

OpenSSL comes with pkgconfig files in ${prefix}/lib64/pkgconfig, and that directory is in our pkgconfig search path: https://github.com/JuliaPackaging/BinaryBuilderBase.jl/blob/b52b7a18bddda8c9a42fbd819b06a4183386bf5a/src/Runner.jl#L1207 but maybe that package wasn't using pkgconfig for finding OpenSSL.

Ok, now we know how to deal with this situation, so we can go on with this one. Thanks for the tips!