With two versions/flavors of OpenSSL installed, the build might end up linking both

[Zirias]

On FreeBSD, we have OpenSSL (currently 1.1.1) in base, installed in /usr. Users can opt to additionally install OpenSSL 3 or LibreSSL from ports (installed in /usr/local) which should then be used for building software instead of the base version.

Unfortunately, the build of libwebsockets ends up linking both at the same time. Tracking this down, I found cmake's OpenSSL detection correctly finds the version installed in /usr/local, with full paths to the libraries. But then, the build also asks pkg-config, which gives just library names without paths, and appends the results. As /usr/lib is in the library search path as well, the base OpenSSL version gets linked additionally.

For FreeBSD, I could easily solve this by just removing pkg-config, see https://cgit.freebsd.org/ports/tree/net/libwebsockets/files/patch-lib_tls_CMakeLists.txt?id=986cbcf341d665b3c0ca454f76fb98e6c5a690cb

I think the build should not use both results combined but rather use some fallback (or indeed not use pkg-config here at all)

On a slightly related side note: https://github.com/warmcat/libwebsockets/blob/main/READMEs/README.libressl.md?plain=1#L23 this example should probably not add libtls.a. It's an alternative API of LibreSSL and not related to its OpenSSL-compatible libraries.

[zzblydia]

Does it still cause issues in the latest v4.3.3 version(it links the library with an absolute path)?

when you are using non-distro SSL(same with you having two different versions of the OpenSSL library in your environment), you should specify which library to use through cmake parameters (-DLWS_OPENSSL_INCLUDE_DIRS=/usr/local/include/openssl -DLWS_OPENSSL_LIBRARIES="/usr/local/lib64/libssl.so;/usr/local/lib64/libcrypto.so").