You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm testing GStreamer's gst-plugins-rs integration in Windows. I got a linker failure when linking against the GStreamer bindings, which does not seem to have an apparent cause (logs in the gist here, since the linker line is massive).
However, upon looking at the reference to CoTaskMemFree, I recalled I'd seen this failure before when testing nuwen.net's flavor of GCC. The probe code here:
never checks if the library being linked is dynamic or static. If it's the latter, then the objects in Libs.private need to be taken into account, and the --static flag must be passed to pkg-config. Otherwise, those symbols are never resolved. I believe this was written implicitly assuming the ELF model of static libraries.
Hi,
I'm testing GStreamer's gst-plugins-rs integration in Windows. I got a linker failure when linking against the GStreamer bindings, which does not seem to have an apparent cause (logs in the gist here, since the linker line is massive).
However, upon looking at the reference to
CoTaskMemFree
, I recalled I'd seen this failure before when testing nuwen.net's flavor of GCC. The probe code here:pkg-config-rs/src/lib.rs
Lines 395 to 404 in 576f550
never checks if the library being linked is dynamic or static. If it's the latter, then the objects in
Libs.private
need to be taken into account, and the--static
flag must be passed to pkg-config. Otherwise, those symbols are never resolved. I believe this was written implicitly assuming the ELF model of static libraries.cc @nirbheek
The text was updated successfully, but these errors were encountered: