Remove version number from shared lib depencies - cmake

I have own project - security_storage - with own OpenSSL package.
The openssl libs are next:
libcrypto.so
libssl.so
I build my project with cmake. Project have several dependcies, including openssl libs:
target_link_libraries(${LIBRARY_NAME} PUBLIC
my_static_lib
...
crypto
ssl
)
After compilation my binary have next dependecies:
ldd ./bin/security_storage
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
But there are no shared libs with version, because my OpenSSL libs doesn't have version number.
How to remove version number from binary dependecies?

I resolved my issue!
The problem were next:
I copy my openssl lib from another folder
The source folder contains symlinks.
I copied only symlinks without library.
Symlinks without library are referenced to the system openssl lib!
The solution is copy from custom openssl folder with symlinks and libs.

Related

install targets after pybind11_add_module in cmake and Yocto

I am trying to use python to interfacing my own c++ library. Actually I can do it manually copying pybind11_example.so to the target device. I hope to do this by using install(TARGETS...
I found this link. But it doesn't help in my Yocto build.
This is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.14.4)
project(pybind11_example)
set(CMAKE_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../lib/math/include")
find_package(PythonLibs REQUIRED)
set(PYTHON_MODULE_EXTENSION ".so" CACHE INTERNAL "Cross python lib extension")
find_package(pybind11 REQUIRED)
pybind11_add_module(${PROJECT_NAME} pybind11_wrapper.cpp)
target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_INCLUDE_PATH})
target_link_libraries(${PROJECT_NAME} PRIVATE simplemath)
include(GNUInstallDirs)
# without lines below, yocto build works fine
install(TARGETS ${PROJECT_NAME}
COMPONENT python
RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}"
LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}"
ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}")
This is the error from devtool build:
ERROR: pybind11-example-1.0+git999-r0 do_package: QA Issue: pybind11-example: Files/directories were installed but not shipped in any package:
/usr/lib/pybind11_example.so
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
pybind11-example: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: pybind11-example-1.0+git999-r0 do_package: Fatal QA errors found, failing task.
Oops, I found the reason. The problem was not in cmake but in .bb file.
After I add FILES_${PN} += "/usr/lib" in the .bb, it works fine.
For more detail, please see this link.

OPENSSL_ROOT_DIR for cmake

I have built & installed openssl 1.1.1 on my system:
openssl version
OpenSSL 1.1.1h-dev xx XXX xxxx
The respective libcrypto.so and libssl.so are in /usr/local/lib64, headers in /usr/local/include. I created /etc/ld.so.conf.d/usrlocal.conf and added /usr/local/lib64 there to make sure the .so are loadable.
There is an older version (1.0.2) in /usr/lib64/ and /usr/include that i need to keep for other dependencies.
I am trying to compile OQS library (https://github.com/open-quantum-safe/liboqs) that requires
find_package(OpenSSL 1.1.1 REQUIRED)
When I try to compile the library, I get
CMake Error at /usr/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (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.0.2k", but
required is at least "1.1.1" (found /usr/lib64/libcrypto.so)
Call Stack (most recent call first):
/usr/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:443 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.17/Modules/FindOpenSSL.cmake:450 (find_package_handle_standard_args)
CMakeLists.txt:26 (find_package)
I have tried setting OPENSSL_ROOT_DIR to almost any value imaginable without any result; the error remains.
It seems to me thatcmake only attempts to check OPENSSL_ROOT_DIR as last attempt, and that it terminates exploration for appropriate library version after finding the first suitable version...
Now the question is obvious - how to force CMAKE to find appropriate OpenSSL version?
UPDATE
(debunked in next update) As #Tsyvarev suggested in the comments, setting OPENSSL_ROOT_DIR as environment variable helped. That means no set(OPENSSL_ROOT_DIR ...) in CMakeLists.txt or -DOPENSSL_ROOT_DIR with cmake command, but export OPENSSL_ROOT_DIR=... is what helped find_package to find the correct version.
I am still running into issues with OQS, yet this time I believe they are caused by a different issue.
lib/liboqs.a(fips202x4.c.o): In function `keccak_squeezeblocks4x.constprop.1':
fips202x4.c:(.text.keccak_squeezeblocks4x.constprop.1+0x6b): undefined reference to `KeccakP1600times4_PermuteAll_24rounds'
UPDATE 2
I am actually using OQS in another CMakeLists.txt via FetchContent as:
FetchContent_Declare(liboqs
GIT_REPOSITORY https://github.com/onavratil-monetplus/liboqs
#GIT_TAG 0.2.0
)
I made my custom fork and tweaked their CMakeLists.txt to export targets so that I can link appropriate dependencies to my binary in cmake:
target_link_libraries(myexecutable PUBLIC OQS::oqs)
The strange thing is, if I let OQS find OpenSSL on its own, I will get to the same result as in the original answer - no matter if I use -D, set() or export =.
However, if on my top level CMakeLists.txt i manually call find_package(OpenSSL 1.1.1 REQUIRED), it succeeds, respective variables OPENSSL_FOUND etc are set properly and OQS compiles. Btw I use cmake version 3.17.2.
After all it was this edit (finding OPENSSL myself) that fixed the problem, this way, -DOPENSSL_ROOT_DIR=/usr/local works as well.
I installed libssl-dev (as suggested at the bottom of the failed cmake build output) and it worked first time.
I had the Problem when I needed openssl for an Android Project. In the scenario it helped to import openssl via gradle and then linking the fetched lib like described here

Cmake Openssl not found

Want to cross-compile a C application that uses Azure IoT SDK, which unfortunately requires Cmake. Cmake refuses to build my toolchain because it claims that it cannot find Openssl that I've compiled for my target architecture.
I've tried adding OPENSSL_ROOT_DIR to the folder it's in.
SET(OPENSSL_ROOT_DIR /path/to/openssl)
I continually get the error:
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES) (found
version "1.0.2g")
I also tried setting system variables to these folder as the error suggests, but it seemingly ignores them and prompts the same error. I've tried adding it to the same folder as my C compiler also to no avail.
I've run out of things to try and this point and I do not understand why it doesn't work. Any suggestions?
In Linux, I didn't have any problem setting OpenSSL.
In Windows, I solved as explained below.
Try removing CMakeCache.txt file and then do again. The cache Cmake is the main problem.
For instance, I did cmake . -DOPENSSL_ROOT_DIR=C:\openssl-1.0.2 -DOPENSSL_INCLUDE_DIR=C:\openssl-1.0.2\include -DOPENSSL_CRYPTO_LIBRARY=C:\openssl-1.0.2\crypto and everything got solved. The logic is same.
For MacOs I encounter the same error while installing ton'slite client (cmake ~/lite-client)
Solved as follows: I have open the "CMakeCache.txt" file in "liteclient-build" directory, find the line
OPENSSL_INCLUDE_DIR:PATH=OPENSSL_INCLUDE_DIR-NOTFOUND
and change it to with my openssl location
OPENSSL_INCLUDE_DIR:PATH=/usr/local/opt/openssl/include

PKCS11 Windows invalid engine YubiHSM2

it's me again.
I am working with a YubiHSM2 HSM Module and I am trying to set it up for the use of pkcs11 engine which will allow me to use OpenSSL with the HSM.
I am implementing this on Windows, which brings me a lot of trouble.
I HAVE installed OpenSSL 32,64, OpenSC,YubiHSM2 drivers as well as libp11 (built with MSYS2).
The interesting part of my OpenSSL.cnf looks like this:
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = "C:\Windows\System32\opensc-pkcs11.dll"
MODULE_path = "C:\Users\myUser\Desktop\SecureTemial\yubihsm2-sdk\bin\yubihsm_pkcs11.dll"
PIN = "0001password"
init = 0
When I try:
C:\OpenSSL-Win64\bin\openssl.exe req -new -x509 -days 365 -sha256 -config C:\Users\myUser\Desktop\SecureTemial\openssl.cnf -engine pkcs11 -keyform engine -key slot_0-label_my_key -out cert.pem
I receive the following:
C:\OpenSSL-Win64\bin\openssl.exe : invalid engine "pkcs11"
In Zeile:1 Zeichen:2
+ C:\OpenSSL-Win64\bin\openssl.exe req -new -x509 -days 365 -sha256 -c ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (invalid engine "pkcs11":String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(C:\Program Files\OpenSSL\lib\engines-1_1\pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
16056:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto\engine\eng_list.c:339:id=pkcs11
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
Error configuring OpenSSL modules
16056:error:25078067:DSO support routines:win32_load:could not load the shared
library:crypto\dso\dso_win32.c:106:filename(C:WindowsSystem32opensc-pkcs11.dll)
16056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:161:
16056:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
16056:error:260BC066:engine routines:int_engine_configure:engine configuration
error:crypto\engine\eng_cnf.c:141:section=pkcs11_section, name=dynamic_path, value=C:WindowsSystem32opensc-pkcs11.dll
16056:error:0E07606D:configuration file routines:module_run:module initialization
error:crypto\conf\conf_mod.c:173:module=engines, value=engine_section, retcode=-1
I have already checked if the dll's are locked and ran as admin etc.
If you have any clue what's responsable for the trouble here please let me know!
Thank you very much!
This question was one of the first that appeared in my search results when doing some research on a similar topic. As it doesn't have an answer yet, I'll outline the results of my solution:
For using libp11's PKCS#11 engine with OpenSSL, it must be compiled as dynamic engine that is statically linked against the OpenSSL version you are using. As you are using the binaries from Shining Light Productions (a good guess based on the install directory you mentioned in your question), using a MSYS2 version obtained from a third-party resource might not work, neither does using the PKCS#11 library that ships with the OpenSC projects' Windows installers.
Fortunately, the Shining Light Productions' OpenSSL version comes with all required libraries, so you can easily compile libp11 yourself, e.g. by using NMAKE (follow the link to see how to obtain it and how to properly setup your command line for its use):
Download the OpenSSL binaries that meet your requirements (x86 or x64) and install them to the proposed standard destinations (e.g., C:\OpenSSL-Win32 or C:\OpenSSL-Win64). - The makefile of libp11 expects these folders for its bindings.
Download and extract, or clone the libp11 projects' source code.
Open your Windows command-line with NMAKE environment variables set and change to the location of the previously downloaded libp11 files.
When building for the 64 bit version of OpenSSL, you have to set the BUILD_FOR environment variable accordingly. Run
set BUILD_FOR=WIN64
on your command-line.
Now compile the libraries by running
NMAKE /F Makefile.mak
If everything went well, you then have two new libraries within libp11's src folder: libp11.dll and pkcs11.dll. The latter is the PKCS#11 engine to use with your OpenSSL. Copy it to e.g., the Windows libraries folder (System32 for the 32 bit version, SysWOW64 for the x64 version).
Adapt your openssl.cnf file accordingly. Copy
openssl_conf = openssl_init
to the beginning of the file, and the rest to its end:
[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
dynamic_path = "C:\\Windows\\SysWOW64\\pkcs11.dll"
module_path = "C:\\Users\\myUser\\Desktop\\SecureTemial\\yubihsm2-sdk\\bin\\yubihsm_pkcs11.dll"
PIN = "0001password"
Some final notes:
Make sure, that the adapted openssl.cnf file really is picked up by OpenSSL. The OpenSSL installation comes with several example files. By default, the location of the config files for above binaries is C:\Program Files\Common Files\SSL\openssl.cnf for the x64 version and C:\Program Files (x86)\Common Files\SSL\openssl.cnf for the x86 version. But other OpenSSL installations on your system (e.g., from OpenVPN, MingW, MSYS2, and alike that ship with bundled OpenSSL) might interfere with the settings file location. You can ensure the right settings file is used by setting the OPENSSL_CONF environment variable accordingly.
When using double quotes for the Windows paths, make sure to escape the backslashes correctly by using \\ instead of \.
You can safely omit the engine_id and init part of your openssl.cnf's [pkcs11_section].
While libp11's dynamic PKCS#11 engine needs to be compiled against the same architecture (x86 or x64) and libraries as OpenSSL, the module library might be required as 32 bit version (even when running the 64 bit build of OpenSSL). - At least that is what happened within the scenario of our systems (we use Gemalto Safenet e-Tokens, so the Aladdin module libraries that ship with the Safenet Authentication Client).

CMake does not compĂ­le Qt5 generate from buildroot

I generate a tarball with Qt5 using Buildroot 2014.05.
When I uncompressed this files to compile my project using CMake I receive the following error message:
CMake Error at <project> /sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message):
The imported target "Qt5::Core" references the file
"<project>/host/usr/bin/qmake"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/<project>/sysroot/usr/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"
but not all the files it references.
I'm using the cmake configs under
<project>/sysroot/usr/lib/cmake/
and my CMakeLists.txt
set(CMAKE_PREFIX_PATH <project>/sysroot/usr/lib/cmake/QtWidgets/ )
find_package(Qt5Widgets REQUIRED)
Any suggestion?
Buildroot 2014.05 does not have qmake to install
This part: I generate a tarball with Qt5 using Buildroot does make much sense. What do you mean exactly by this ?
If by this you mean that you tarball'ed the contents of output/host/ (which is the toolchain and all the libraries that you need to build applications for your target), then beware that it is not relocatable. So it has to be installed in the same location as the one it was generated in. So for now, if you want to do this, you should set the BR2_HOST_DIR configuration option to something like /opt/<something>/, and then tarball that up and uncompress it on the other machines where you want to use the toolchain.
It's in our TODO-list to make this relocatable.