The_Great_Archive/RetroShare
1
0
Fork 0
mirror of https://github.com/RetroShare/RetroShare.git synced 2026-09-12 11:40:17 +05:00
Code Issues Packages Projects Releases Wiki Activity

build(friendserver): link OpenSSL again (needed via inlined libretroshare headers)

Browse Source 
Removing OpenSSL from the friendserver in the previous round was wrong: although
friendserver sources don't #include <openssl/...> directly, friendserver.cc pulls
in libretroshare public headers whose inline functions call the OpenSSL EVP API
(EVP_DigestUpdate, ...). libretroshare links OpenSSL PRIVATE and is built shared on
Windows, so those symbols are not propagated to consumers — the link then fails
with "undefined reference to EVP_DigestUpdate" on MinGW. Link OpenSSL here again.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
jolavillette 2026-06-06 16:27:21 +02:00
parent a53e1e919e
commit 0d83fd26dc
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
retroshare-friendserver/CMakeLists.txt
View File

@ -77,9 +77,13 @@ target_include_directories(${PROJECT_NAME} PRIVATE
)
# Link libraries.
# OpenSSL is intentionally not linked here (no direct use); it is provided
# transitively by libretroshare through the "retroshare" target.
target_link_libraries(${PROJECT_NAME} PRIVATE retroshare)
# OpenSSL must be linked here: friendserver.cc includes libretroshare public
# headers whose inline functions call the OpenSSL EVP API (e.g. EVP_DigestUpdate),
# so those symbols end up referenced in this target's objects. libretroshare links
# OpenSSL PRIVATE (and is built shared on Windows), so it does NOT propagate those
# symbols to consumers, hence the friendserver has to link OpenSSL itself.
find_package(OpenSSL REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE retroshare OpenSSL::SSL OpenSSL::Crypto)
if(WIN32)
# The friendserver uses the Winsock API directly (src/network.cc: