Open Zirias opened 1 year ago
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").
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 askspkg-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=986cbcf341d665b3c0ca454f76fb98e6c5a690cbI 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.