shinchiro/mpv-winbuild-cmake

Build issues

Closed this issue · 2 comments

  • (I think 0d71c33 can be reverted; mirror/mingw-w64@4895209 was just added which makes the breaking change opt-in)

  • In ffmpeg.cmake, I had to add -DJXL_STATIC_DEFINE -DJXL_THREADS_STATIC_DEFINE to the extra-cflags otherwise the ffmpeg configure script would fail the libjxl check

    • That said, I still couldn't get ffmpeg to build with libjxl, so I just disabled the support:
      /home/fp/mpv-winbuild-cmake/build64/install/lib/gcc/x86_64-w64-mingw32/11.3.1/../../../../x86_64-w64-mingw32/bin/ld: /home/fp/mpv-winbuild-cmake/build64/install/mingw/lib/libjxl.a(decode.cc.obj):decode.cc:(.text+0x2c3): undefined reference to operator new(unsigned long long)'
      and it goes on and on. Apparently, ffmpeg uses gcc for its test instead of g++.
  • My freetype2 build ended up linking to the dynamic version of Brotli for some reason (parallelisation?), which caused an issue when the ffmpeg configure script tried to test linking to libbluray. I added --with-brotli=no to freetype2.cmake. I checked: Freetype's libbrotli support is related to support for WOFF fonts, which doesn't really seem relevant to mpv

fyi, I start compiling from fresh with new mingw git changes until compiling mpv and I get no error like yours. Also commit 0d71c33 is not even need in my opinion. Probably there's something wrong with your setup

Also commit 0d71c33 is not even need in my opinion

You're right - I mention that in my first point. I did need it at that point because the upstream header changes where __attribute__ ((dllimport)) was added to all the pthread functions did cause linking failure. It just so happened that another change was introduced upstream to fix it after my issue was created. I also had a gcc-related error on GH Actions, as a result of that upstream commit

The rest could indeed be setup-related, thanks for your time