How can I link to libwinpthread libc++ and libunwind statically?
#311
Comments
|
Just a question: why don't you use the native w32 thread wrapper in ffmpeg? |
tommyvct
changed the title
libwinpthread statically?libwinpthread libc++ and libunwind statically?
|
Because I didn't decide this. https://github.com/tommyvct/obs-deps/blob/master/deps.ffmpeg/99-ffmpeg.zsh#L164 |
The reason for the failure to link, is because when you add the flag Something like The This should show the exact command used to run the linking - something like this: (It does include a couple other commands too, but this is the interesting one.) At the end of the output of that command, there's a long command line that looks something like this: This is the interesting one - if you can provide that, for the working GCC case (plus for the failing llvm-mingw case) it'd let me know more about what's going on. But TL;DR, adding a Other than that - there's another quite hacky but effective way of making sure that it doesn't link these libraries as dynamic. If you just remove the files |
|
I did some further research: FFmpeg is innocent, but it's dynamically linked dependencies, namely I'll come back later for your experiment. |
|
@mstorsjo This is from the llvm lld: The questions are:
|
|
In our implementation, we did use the DLL renaming hack to force static linkage. After reimplementing the renaming hack, both During compilation, a warning |
|
While compiling srt for Windows ARM64, the produced pkg-config file has a major problem: Look at the All the changes between x64 and ARM64 builds are 1) change of toolchain, from mingw-gcc to mingw-llvm and 2) get rid of Now, if we get rid of the cursed We need a better way to eliminate |
It's some GCC program which is used as a wrapper for invoking the linker - I don't actually remember exactly what role it has. For this investigation, it's role is irrelevant anyway.
Now that's a good question - from that linker invocation, it does look like GCC/binutils should run into the same issue too - but apparently it doesn't. I guess I'd have to try this out for myself to see why it happens to work there. In principle though, adding it in the GCC case would be safer too, you're more or less just lucky that it has worked so far, I'd say. Also, notice how the
That's because
The ELF linker interface of lld probably supports it, while the mingw interface doesn't yet. I haven't run into any case actively using this option in the last 4 years so it hasn't needed to be implemented yet.
Yes, clearly. On first sight, it looks like a bug in whatever build files libsrt uses for creating the pkg-config files (or more precisely, for gathering info about what to put in it). How does one reproduce that issue? Does this library need a bazillion of dependencies, or can it be built on its own? |
This library itself only depends on mbedtls, but outside of our use case it is optional, since srt can use system openssl as it's default crypt library. To reproduce the bug:
|
I had a look now, and it just so happens to work due to a different circumstance. When But due to surprising circumstances, the MSVC style library form Normally you wouldn't have libraries named
Thanks for the instructions on building it. It looks like if the compiler links against some of its standard libraries with an unusual syntax, |
deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment)
deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment)
deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment)
deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment)
deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment) deps.qt: Add support for Windows ARM64 deps.windows: Add support for Windows ARM64 deps.ffmpeg: Add support for Windows ARM64 deps-ffmpeg: restore -Bdynamic after -Bstatic ref: mstorsjo/llvm-mingw#311 (comment) deps.qt: Add support for Windows ARM64 deps.windows: Add support for Windows ARM64
The fix for this issue is now available in the prerelease with LLVM 16.0.0 RC 1: https://github.com/mstorsjo/llvm-mingw/releases/tag/20230130 If there's nothing more to follow up on here in this issue, I believe this issue can be closed, and new issues can be opened for other more targeted issues if there are other things to look into. |
Background: I'm compiling FFmpeg for OBS Studio's dependency. Currently, FFmpeg and it's dependencies are cross-compiled from Linux. Because we are targeting Windows ARM64 platform, this toolchain is our only hope other than MSVC, which requires a substantial infrastructure rewrite.
In our own build of FFmpeg, for x64 targets, we used GNU toolchain and linked against
libwinpthreadstatically like this:where
ff_ldflagswill be one part of the configure script invocation.But when I switched to LLVM-MinGW toolchain, this LD flag will somehow make FFmpeg failed to find what it just compiled:
If I remove the suspicious LD flags altogether, the compilation will success but pthread will be dynamically linked.
Ref #273
The full FFmpeg configure invocation is here:
The text was updated successfully, but these errors were encountered: