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

Cross-compile libsrtp to Windows (64-bit) is failing given that OpenSSL can't be found #652

Open
TSC21 opened this issue Jul 12, 2023 · 1 comment

Comments

@TSC21
Copy link

TSC21 commented Jul 12, 2023

I am trying to cross-compile libdatachannel to Windows, which depends on libsrtp, using dockcross (more specifically, https://github.com/dockcross/dockcross/tree/master/windows-static-x64) in Ubuntu 20.04. This container image in specific uses MXE together with the x86_64-w64-mingw32 compiler.

OpenSSL (v1.1.1) is also built through this container using the following configuration and build command: (note this is being called from CMake, and so the usage of CMake variables)

# Config
perl <SOURCE_DIR>/Configure mingw64 no-shared no-tests --prefix=${CMAKE_INSTALL_PREFIX}
# build
RC=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-windres
AR=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-ar
RANLIB=/usr/src/mxe/usr/bin/x86_64-w64-mingw32.static-ranlib
CROSS_COMPILE=x86_64-w64-mingw32.static-
make -e RC=${RC} AR=${AR} RANLIB=${RANLIB} CROSS_COMPILE=${CROSS_COMPILE}

The command above runs properly and libcrypto.a and libssl.a are both installed in ${CMAKE_INSTALL_PREFIX}/lib, besides the headers on the ${CMAKE_INSTALL_PREFIX}/include folder. Here's the install tree structure:

.
├── bin
│   ├── ...
│   └── openssl.exe
├── include
│   ├── ...
│   └── openssl
│      ├── ...
│      └── ssl.h
├── lib
│   ├── ...
│   ├── libcrypto.a
│   └── libssl.a
...

But, for some reason, libsrtp when calling find_package(OpenSSL REQUIRED), fails to find OPENSSL_CRYPTO_LIBRARY as it can be seen above. Note that OPENSSL_INCLUDE_DIR had to also be passed as a CMAKE_ARG to build lidatachannel because FindOpenSSL() is was also not able to find openssl/ssl.h, although it is installed in ${CMAKE_INSTALL_PREFIX}/include. OpenSSL is marked as a dependency of libdatachannel while building through CMake, so I don't necessarily understand why this fails. One thing to note is that MXE sets MSYS to 1, and also since we are using mingw32 to cross-compile,WIN32 and MINGW are also set to 1. If I try to manually set MINGW and WIN32 to 0, then find_package(OpenSSL) succeeds and the build process continues, until the linker fails because the architecture is of course wrong.

This is the error seen:

-- Compiler flags (CMAKE_C_FLAGS):  -std=c99 -pedantic -Wall -Wextra -Wfloat-equal -Wshadow -Wpointer-arith -Wunreachable-code -Winit-self -Wno-unused-function -Wno-unused-parameter -Wno-unreachable-code -Wstrict-prototypes -Werror
-- link library: ws2_32
-- Configuring done
CMake Error at /usr/src/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.20/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
  version "1.1.1o")
Call Stack (most recent call first):
  /usr/src/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/src/mxe/usr/x86_64-pc-linux-gnu/share/cmake-3.20/Modules/FindOpenSSL.cmake:571 (find_package_handle_standard_args)
  deps/libsrtp/CMakeLists.txt:75 (find_package)

Is this potentially a problem with the OpenSSL build or even with the default FindOpenSSL.cmake module? Or is this something that can be addressed on libsrtp CMakeLists.txt? Any help with this would be appreciated.

Thanks in advance!

@pabuhler
Copy link
Member

Hi @TSC21,
Did you find a solution for this ?
I don't have much experience in use cmake in this way to pull in dependencies, when I have used cmake and libsrtp in small cmake based projects I have either just let it find the system install or else used OPENSSL_ROOT_DIR if I need to point to a specific install.
It is our aim to have cmake build that follows best practice but it is not always obvious what that is.
If you find out what is wrong and how to fix it then please make a PR otherwise I do not think we will prioritizing fixing this.

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

2 participants