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

LibOQS CMake fails with cmake 3.28.3 #1748

Closed
wpj3799 opened this issue Apr 4, 2024 · 4 comments · Fixed by #1873
Closed

LibOQS CMake fails with cmake 3.28.3 #1748

wpj3799 opened this issue Apr 4, 2024 · 4 comments · Fixed by #1873

Comments

@wpj3799
Copy link

wpj3799 commented Apr 4, 2024

CMake of liboqs fails on Kali Linux VM images and Kali Linux WSL

On a clean image I ran:

  1. sudo apt install astyle cmake gcc ninja-build libssl-dev python3-pytest python3-pytest-xdist unzip xsltproc doxygen graphviz python3-yaml valgrind libgmp3-dev git libssl-dev
  2. git clone https://github.com/open-quantum-safe/liboqs.git
  3. cd liboqs
  4. cmake -GNinja -DOQS_USE_OPENSSL=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/usr

It throws this error which I don't understand since it finds the library v3.1.5?:
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.

-- The C compiler identification is GNU 13.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test CC_SUPPORTS_WA_NOEXECSTACK
-- Performing Test CC_SUPPORTS_WA_NOEXECSTACK - Success
-- Performing Test LD_SUPPORTS_WL_Z_NOEXECSTACK
-- Performing Test LD_SUPPORTS_WL_Z_NOEXECSTACK - Success
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Alg enablement unchanged
CMake Error at /usr/share/cmake-3.28/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 (missing: OPENSSL_CRYPTO_LIBRARY) (found
suitable version "3.1.5", minimum required is "1.1.1")
Call Stack (most recent call first):
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.28/Modules/FindOpenSSL.cmake:668 (find_package_handle_standard_args)
CMakeLists.txt:135 (find_package)

Environment:

  • WSL: Linux 4.4.0-19041-Microsoft #3996-Microsoft x86_64 GNU/Linux
  • Kali VM: Linux 6.6.9-amd64 Kali 6.6.9-1kali1 x86_64 GNU/Linux
  • liboqs main branch
  • which make -> /urs/bin/cmake
  • cmake v.3.28.3

Not sure if this is a bug or a Kali issue but, any help would be appreciated.

@SWilson4
Copy link
Member

SWilson4 commented Apr 5, 2024

Thanks for the bug report!

This appears to be a regression in CMake. I reproduced your error in a kali-rolling image with CMake 3.28.3. Everything worked fine, however, with CMake 3.25.1.

It's probably worth bringing this to the attention of the CMake team. For now, the following command worked for me with CMake 3.28.3:

cmake -GNinja -DOQS_USE_OPENSSL=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/usr -DOPENSSL_ROOT_DIR=/usr/lib/x86_64-linux-gnu

Please let me know if that works for you.

@wpj3799
Copy link
Author

wpj3799 commented Apr 5, 2024

Yes, that seems to have worked. Thank you.

@baentsch
Copy link
Member

baentsch commented May 7, 2024

The same problem occurs in Ubuntu 24. I'm afraid we need to provide a workaround in OQS if we want to support that LTS release.

@SWilson4
Copy link
Member

On my way to file a CMake bug report, I noticed this commit: https://gitlab.kitware.com/cmake/cmake/-/commit/5cc8a69867ac42333a656607d90059a6db823abd. Newer version of CMake take the (reasonable, in my opinion) approach of trusting a user-defined OPENSSL_ROOT_DIR and not searching elsewhere for OpenSSL...

... meanwhile, we hardcode OPENSSL_ROOT_DIR to /usr on Linux whenever OPENSSL_ROOT_DIR is not set by the user. I've made #1873 to correct this.

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

Successfully merging a pull request may close this issue.

3 participants