CMake - wskazanie OpenSSL

0

Witam, w projekcie mam inną wersję OpenSSL, niż zainstalowaną na maszynie.
Pousuwałem z PATH wszystko, co mogłoby zaprowadzić QtCreatora / CMake'a do tego nowszego OpenSSL'a
użyłem dodatkowo:

set(OpenSSL_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/OpenSSL-Win)

niestety mimo że widzę jak podczas kompilacji podaje

.. \thirdparty\OpenSSL-Win\lib\ssleay32.lib  ..\thirdparty\OpenSSL-Win\lib\libeay32.lib 

to koniec końców gdzieś znajduje sobie OpenSSL-a nowszego i aplikacja domaga się jego (nowszego).
Nie mam pojęcia, co jeszcze robię źle.

Używam Qt Creatora MSVC 2017 32 bit CMake 3.16 OpenSSL 1.0.2p Windows 7

0

Ale kiedy się domaga tego nowszego? Przy uruchomieniu? Jeśli tak to dołączaj właściwą wersję wraz z programem.

2

Dodaj -DOPENSSL_ROOT_DIR=ScieżkaDoOpenSSL oraz -DOPENSSL_LIBRARIES=ScieżkaDoOpenSSLLib jak pierwszy raz uruchamiasz cmake.

cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl -DOPENSSL_LIBRARIES=/usr/local/ssl/lib

Albo jeszcze inaczej: https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode

find_package(OpenSSL PATHS ${CMAKE_CURRENT_SOURCE_DIR}/OpenSSL-Win NO_DEFAULT_PATH)
0

@kq: Tak, przy uruchomieniu aplikacja domaga się nowszej wersji, chociaż widzę jak podczas budowania debug cmak'a ma podane przeze mnie tą niższą wersję z projektu.
@MarekR22 po dodaniu tego ```
PATHS ${CMAKE_CURRENT_SOURCE_DIR}/OpenSSL-Win NO_DEFAULT_PATH

Could NOT find OpenSSL (missing: OpenSSL_DIR)

a ustawiłem mu:

set(OpenSSL_DIR ${CMAKE_CURRENT_SOURCE_DIR}/OpenSSL-Win )
1

Tak, przy uruchomieniu aplikacja domaga się nowszej wersji, chociaż widzę jak podczas budowania debug cmak'a ma podane przeze mnie tą niższą wersję

Samo z siebie się nie domaga, jak konkretnie wygląda log?

Możesz też spróbować "młotkiem", skopiowałem z któregoś z moich projektów, popraw pod siebie nazwy libek:

set(OPENSSL_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/OpenSSL-Win CACHE INTERNAL "${PROJECT_NAME} OpenSSL Root Directory" FORCE)
add_library(openssl INTERFACE)
target_include_directories(openssl SYSTEM INTERFACE "${OPENSSL_ROOT_DIR}/include/")
file(GLOB OPENSSL_SOURCE_FILES ${OPENSSL_ROOT_DIR}/include/openssl/*.h)
target_sources(openssl INTERFACE ${OPENSSL_SOURCE_FILES})
target_link_libraries(openssl INTERFACE
        ${OPENSSL_ROOT_DIR}/lib/libssl.a
        ${OPENSSL_ROOT_DIR}/lib/libcrypto.a
        )

Wtedy używasz tego tak:

target_link_libraries(${PROJECT_NAME}Static
    openssl
)
0
BartoSAS napisał(a):

Witam, w projekcie mam inną wersję OpenSSL, niż zainstalowaną na maszynie.

Czy "w projekcie" oznacza w pliku CMakeLists.txt? Czy jest ustawiona przez find_package() ? Czy korzystasz ze standardowego modułu do szukania OpenSSLa który jest w cmake'u czy z własnego pliku config?
Skoro masz w projekcie ustawioną jakąś wersję OpenSSLa to znaczy, że autor chciał aby tą wersję użyć (inaczej nie użyłby konkretnego numeru wersji w find_package()), więc może powinieneś zupgrejdować to co masz na maszynie.
Jeśli masz pewność, że wersja, którą masz zainstalowaną zadziała, czemu nie usuniesz numeru wersji z find_package?
Możesz też przeszukać w CMakeCache'u wszystkie zmienne zawierające OpenSSL (OpenSSL_DIR, OpenSSL_INCLUDE_DIR, etc) i podmienic je.
Jeśli nadal będziesz miał problemy, wklej kawałek kodu Cmake'a, który odnosi się do OpenSSLa.

0

Po instrukcji od @several "dobiegłem" do stanu:

-- Could NOT find OpenSSL (missing: OpenSSL_DIR)
ninja: error: 'ssl-NOTFOUND',

CMakeLists dotyczący openssl

project(openssl)

set(OPENSSL_ROOT_DIR ${CMAKE_CURRENT_SOURCE_DIR} CACHE INTERNAL "" FORCE)
    find_package(OpenSSL 1.0.2 PATHS ${OpenSSL_ROOT_DIR} NO_DEFAULT_PATH)
    add_library(openssl INTERFACE)

    add_library(ssl SHARED IMPORTED GLOBAL)
    add_library(crypto SHARED IMPORTED GLOBAL)
0

@BartoSAS: Gdybyś zrobił wg. mojej instrukcji to by działało. Mieszasz dwa całkowicie różne podejścia do problemu bez zastanowienia. Moje podejście polega na tym, że tworzysz osobny target o nazwie openssl, równie dobrze mógłbyś ten nowy target nazwać SmieszkiHeheszki by potem użyć go tak target_link_libraries(${PROJECT_NAME}Static SmieszkiHeheszki) i też będzie działać. Nie używaj tego z find_package, tak nie zadziała. Poza tym, nazwałeś swój projekt openssl: project(openssl) czym prawdopodobnie pozbawiłeś się szansy by użyć kodu, który wkleiłem bez zmieniania nazwy targetu.

0

@several: Przepraszam, niedopatrzenie z mojej strony. Poprawiłem ( wyrzuciłem 'project(openssl)' ) i pozbyłem się find_packacge()
Projekt wygląda tak

|
CMakeList
| - InnyLib, gdzie używam target_link_libraries(${PROJECT_NAME} openssl)
| - ThirdParty
    | - - OpenSSL -> CMakeList ( tutaj Twój kod )

Dosotosowałem libki:

target_link_libraries(openssl INTERFACE
            ${OPENSSL_ROOT_DIR}/lib/libeay32.lib
            ${OPENSSL_ROOT_DIR}/lib/ssleay32.lib
            )

próbowałem też z:

target_link_libraries(openssl INTERFACE
            ${OPENSSL_ROOT_DIR}/lib/libeay32MD.lib
            ${OPENSSL_ROOT_DIR}/lib/ssleay32MD.lib
            )

usunąłem cały katalog shadow-builda i po zbudowaniu taki mam rezultat:

Api error "TLS initialization failed" 
QSslSocket::sslLibraryBuildVersionString() : "OpenSSL 1.1.1b  26 Feb 2019"
2

Na ten błąd niestety nic nie poradzisz. Poprawnie zlinkowałeś swoją wersję openssla, ale Qt wymaga wyższej i koniec. Pomiędzy wersją 1.0.2 a 1.1.1 jest za dużo różnic[1] Nie ma to związku z tym:

to koniec końców gdzieś znajduje sobie OpenSSL-a nowszego i aplikacja domaga się jego (nowszego)

To tak nie działa. Qt gdzieś tam w środku ma zahardkodowaną (prawdopodobnie) wersję openssl, której wymaga i porównuje ją z wersją ustawioną w nagłówku biblioteki. Nic tam się nigdzie magicznie nie odnajduje i nie linkuje razem.

[1] Pomiędzy wersją 1.0.2 a w 1.1.1 openssla było trochę zmian np. w inicjalizacji. W wersji wyższej nie trzeba już ręcznie ustawiać zewnętrznej tablicy muteksów oraz callbacku blokującego, żeby móc bezpiecznie używać openssla w wielu wątkach. Efektem tego jest dość minimalistyczna inicjalizacja do typowych potrzeb, bezpieczna w wersji 1.1.0 i wyższej ale niewystarczająca w wersji 1.0.2.

0

Czy jakbym budował w wersji niższej niż 5.12, to problem powinien zostać rozwiązany ?

ale Qt wymaga wyższej i koniec

Podałbyś mi źródło, gdzie oni to zapisali? Ja znalzłem tylko to qt-5-12-4-released-support-openssl-1-1-1 , ale nie połączyłem kropek w głowie, że może to być to.

0

Nie muszę nic szukać, w tym linku który wrzuciłeś jest napisane:

As an important new item it provides binaries build with OpenSSL 1.1.1

Czyli dla tej wersji, jeśli używasz binarek z oficjalnego źródła, musisz użyć openssl 1.1.1. Strzelam, że nie wycięli supportu dla 1.0.2, tak więc być może jest możliwość zbudowania Qt ze źródeł z wersją 1.0.2. Ale to tylko moje gdybanie.

1

Sprawdziłem. Informacja dla potomnych:

Jak ktoś będzie kiedykolwiek miał podoboną sytuację ( ma gdzieś stare API OpenSSL-a ) i potrzebuje Qt 5.12 to ( w chwili pisania tej wiadomości ) 5.12.3 obsługuje starego OpenSSL-a.

1 użytkowników online, w tym zalogowanych: 0, gości: 1