Skip to content

fix(build): add missing picotls dependencies for static linking#25

Open
mmokhi wants to merge 1 commit intoEndPositive:mainfrom
mmokhi:mmokhi/fix-build-static
Open

fix(build): add missing picotls dependencies for static linking#25
mmokhi wants to merge 1 commit intoEndPositive:mainfrom
mmokhi:mmokhi/fix-build-static

Conversation

@mmokhi
Copy link
Copy Markdown

@mmokhi mmokhi commented Jan 24, 2026

When building with -Ddefault_library=static, the linker fails with undefined references to ptls_* symbols (e.g., ptls_free, ptls_aead_new).

It seems that Meson's CMake integration does not propagate transitive dependencies, so we seem to have to make it explicit.

When building with -Ddefault_library=static, the linker fails with
undefined references to ptls_* symbols (e.g., ptls_free, ptls_aead_new).

It seems that Meson's CMake integration does not propagate
transitive dependencies, so we seem to have to make it explicit.
@EndPositive
Copy link
Copy Markdown
Owner

this doesn't seem to build on my machine anymore, see:

2.253 picoquic| Subproject picoquic finished.
2.253 
2.253 Run-time dependency threads found: YES
2.253 
2.253 meson.build:106:16: ERROR: The CMake target picotls-fusion does not exist
2.253   Use the following command in your meson.build to list all available targets:
2.253 
2.253     message('CMake targets:\n - ' + '\n - '.join(<cmake_subproject>.target_list()))
2.253 
2.253 A full log can be found at /usr/src/app/meson-build-release/meson-logs/meson-log.txt

can you make sure the docker image succeeds the build? also I'm not sure exactly why you need this, so a little extra explanation would be nice :)

@ImanSeyed
Copy link
Copy Markdown
Contributor

The static link failure comes from how picoquic's CMake finds and links picotls. FindPTLS.cmake doesn't define CMake targets. It only returns raw library file paths in PTLS_LIBRARIES (with find_library).

find_library(PTLS_CORE_LIBRARY picotls-core HINTS ${PTLS_HINTS})
find_library(PTLS_OPENSSL_LIBRARY picotls-openssl HINTS ${PTLS_HINTS})
find_library(PTLS_FUSION_LIBRARY picotls-fusion HINTS ${PTLS_HINTS})
find_library(PTLS_MINICRYPTO_LIBRARY picotls-minicrypto HINTS ${PTLS_HINTS})

set(PTLS_LIBRARIES
    ${PTLS_CORE_LIBRARY}
    ${PTLS_OPENSSL_LIBRARY}
    ${PTLS_FUSION_LIBRARY}
    ${PTLS_MINICRYPTO_LIBRARY})

These variables are things like /usr/lib/x86_64-linux-gnu/libpicotls-core.a. When picoquic-core is linked with target_link_libraries(... PUBLIC ${PTLS_LIBRARIES}), CMake treats those as plain link flags and doesn't record them in the target's INTERFACE_LINK_LIBRARIES. That's why Meson sees picoquic-core as depending only on Threads, even though it actually requires several picotls static libraries. This is hidden when building shared libraries (the dynamic loader pulls picotls in with DT_NEEDED) and also hidden on Arch because picotls there provides proper CMake targets, so FindPTLS.cmake is bypassed. The same issue affects picoquic-log, which doesn't declare any link dependency on picotls or picoquic-core at all. In short, picoquic is linking picotls with raw paths instead of targets, so CMake can't export the true dependency graph.

@mmokhi
Copy link
Copy Markdown
Author

mmokhi commented Jan 26, 2026

this doesn't seem to build on my machine anymore, see:

2.253 picoquic| Subproject picoquic finished.
2.253 
2.253 Run-time dependency threads found: YES
2.253 
2.253 meson.build:106:16: ERROR: The CMake target picotls-fusion does not exist
2.253   Use the following command in your meson.build to list all available targets:
2.253 
2.253     message('CMake targets:\n - ' + '\n - '.join(<cmake_subproject>.target_list()))
2.253 
2.253 A full log can be found at /usr/src/app/meson-build-release/meson-logs/meson-log.txt

can you make sure the docker image succeeds the build?
Yep sure, I try to look at it later today to see why docker image doesn't build (technically I'm just changing the binary build)

also I'm not sure exactly why you need this, so a little extra explanation would be nice :)

The exaplanations from @ImanSeyed is rather more complete than all I could say 😄 but if I want to add more context: Since docker image was not starting up well (the server binary would just coredump due to a thread problem) , I investigated this further and noticed it's due to mismatch with (not-)linked libraries and when tried to build the static binary I had linking errors.
And for the reason stated by @ImanSeyed I made changes so it links properly, and it built well.

@mmokhi
Copy link
Copy Markdown
Author

mmokhi commented Jan 26, 2026

@EndPositive I just tried to build the docker image (on my branch), using a simple docker build and it builds without problem 🤔

Do you happen to use any flags in particular that I should use while building?

(I use --no-cache to make sure it's a fresh build)

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

Successfully merging this pull request may close these issues.

3 participants