Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not possible to install also in WSL #8

Open
marcoCalipari opened this issue May 17, 2023 · 4 comments
Open

Not possible to install also in WSL #8

marcoCalipari opened this issue May 17, 2023 · 4 comments

Comments

@marcoCalipari
Copy link

Problem

After failing to install on Kali, I decided to do it also to give a try on WSL running Debian.
However, when I try to build this time I cannot let cmake understand that I have openssl3 installed, and that openssl1.1 is not even in my pc.

Log of Cmake

CMake Error at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR: Found unsuitable version "1.1.1n", but required is at least "3" (found /usr/lib/x86_64-linux-gnu/libcrypto.so, found components: Crypto SSL) Call Stack (most recent call first): /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:598 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.25/Modules/FindOpenSSL.cmake:613 (find_package_handle_standard_args) lib/openssl3.cmake:85 (find_package) CMakeLists.txt:168 (include)

My SSL

openssl version -a OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) built on: Wed May 17 09:51:47 2023 UTC platform: linux-x86_64 options: bn(64,64) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG OPENSSLDIR: "/usr/local/ssl" ENGINESDIR: "/usr/local/ssl/lib64/engines-3" MODULESDIR: "/usr/local/ssl/lib64/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0xfffab2235f8bffff:0x18405fc6f1bf27ab

Also the libraries are in the correct place:

which openssl /usr/local/ssl/bin/openssl

I have no iedea how to solve this problem, given also by the fact that I am not familiar with cmake.
Thanks in advance for all your support

@aloisklink
Copy link
Contributor

Hi @marcoCalipari, it looks like the brski CMake files finds OpenSSL using the FindOpenSSL CMake module.

By default, it looks at your OS libraries, and since the current latest version of Debian, Debian 11 (Bullseye)1 only comes with OpenSSL 1.1.1n, that's the one it finds first.

If you're using WSL, it might just be easier to spin up a Debian 121/Ubuntu 22.04 image, since those distros use OpenSSL 3.

If you do want to use an older OS, you can change where CMake looks for OpenSSL by setting the OPENSSL_ROOT_DIR CMake variable:

OPENSSL_ROOT_DIR

Set to the root directory of an OpenSSL installation.

Taken from https://cmake.org/cmake/help/v3.26/module/FindOpenSSL.html#hints

You can set this variable in CMake's CLI by using cmake's -D option, e.g.:

cmake -S . -B build/ -DOPENSSL_ROOT_DIR=/path/to/your/openssl/version

Alternative (let brski compile OpenSSL for you)

Alternatively, you can let brski compile OpenSSL for you! It's a bit slow, and you might also need to install OpenSSL's dependencies then, but it's worth a try! To do this, you can:

Footnotes

  1. Debian 12 (Bookworm) is coming out soon on 2023-06-10, and will have OpenSSL 3.0.9! 2

@mereacre
Copy link
Contributor

mereacre commented Jun 6, 2023

@marcoCalipari Updated the main README.md with the details on the OpenSSL library.

@mcr
Copy link
Collaborator

mcr commented Jun 7, 2023 via email

@aloisklink
Copy link
Contributor

I had the ssl1.1.1 vs 3.x problem, and given that the repo will go build 3.x regardless,
I thought that the check was going to be removed.

I'm for building OpenSSL by default (e.g. by making -DBUILD_OPENSSL3_LIB=ON the default option), but I think there should still be an option to link to a pre-installed OpenSSL library for the following reasons:

  • Cross-compiling is a lot easier if you don't also need to worry about cross-compiling dependencies.
  • Dynamic linking is required if we ever want to publish anything to a package repository
  • Linking to a pre-installed OpenSSL is much much faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants