Closed agnickolov closed 2 weeks ago
You are suggesting
- target_link_libraries(datachannel-static PRIVATE LibJuice::LibJuice)
+ target_link_libraries(datachannel-static PRIVATE LibJuice::LibJuiceStatic)
but even the static triplets build provide LibJuice::LibJuice
.
If I look into the installed juice.h
, I would guess that the problem is that it would need a JUICE_STATIC
definition for static usage, or a simple fixup in the portfile which removes the need for the definition.
I suggested what seemed like the most simple and logical change to make. Presumably LibJuiceStatic
provides the right definitions for its dependents. If it doesn't then that's a problem within libjuice
, not libdatachannel
. I'm not opposed to a different solution as long as my project builds and works, however.
Any update here? Nothing seems to have been fixed one way or another...
@dg0yt Please help take a look at #40328 to see if there is a better solution. Thanks🌼
Thanks @MonicaLiu0311. The idea was a little different. I will take a look.
My proposal: #40335.
Which really removes the needed for using JUICE_STATIC
downstream.
And #40337 provides a similar update+cleanup+fixup to libdatachannel
.
Operating system
Windows
Compiler
MSVC
Steps to reproduce the behavior
Build a project using static CRT linkage (
VCPKG_TARGET_TRIPLET=x64-windows-static
) that depends onlibdatachannel
. The project generates fine. However, trying to link an executable within the generated workspace fails with errors withinlibdatachannel
. It is configured to use the DLL version of its dependencylibjuice
, but vcpkg builds the static version of that library as instructed.Failure logs
Additional context
The problem lies within the following construct within
libdatachannel
's CMakeLists.txt (lines 418-430):vcpkg uses the system version of the above code due to
-DPREFER_SYSTEM_LIB=ON
in the portfile. However, the above code instructs the generator to always use alibjuice
shared library as a dependency oflibdatachannel
. According to the author this is actually intended. However, in the build model within the vcpkg port the external library flavor depends on the linkage for the project. Therefore the above should be modified with a patch within the port to discriminate the dependency:The else clause is irrelevant and doesn't need to be patched. Only the last line in the if clause above needs to be patched.