Help compiling x264 from source on Cygwin - fatal errors unless AVS is disabled

[nevcairiel]

I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.

[Groucho2004]

Originally Posted by nevcairiel

I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.

Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.

[masterkivat]

Originally Posted by Groucho2004

Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.

Hey Groucho2004, do you have plans to provide your x264 builds for "mere mortals" (like me ) in the future? Would be interesting compare to other providers like LigH, jpsdr and the vanilla ones.

[Groucho2004]

Originally Posted by masterkivat

Hey Groucho2004, do you have plans to provide your x264 builds for "mere mortals" (like me ) in the future? Would be interesting compare to other providers like LigH, jpsdr and the vanilla ones.

My builds are very barebone, no swscale, gpac, ffms, lsmash, etc. I only enable avs support. Apart from that, I think there are enough options around from which to pick.

[Kaos-Industries]

Originally Posted by qyot27

No, you were cross-compiling if you were using mingw. Cygwin doesn't support the win32threads threading mode, and so trying to enable that when doing a native Cygwin build will fail and disable threading. If you're building for MinGW-w64, win32threads is supported.

Hey there, me again. I managed to compile the rest of the packages pretty smoothly, surprisingly enough, but I'm now stuck at the final stage of compiling FFmpeg itself. I'm sorry to bother you with this again, but the officially-recommended avenue by the failed output of the compiler is the FFmpeg mailing list, and it was abrasive and unpleasant, so it looks like I'm stuck coming back to this forum.

After having successfully compiled the binaries and libraries for x264, x265, fdk_aac, libopus and AV1 (aom), and then running the following command to compile the all-important FFmpeg:

cd /ffmpeg_sources &&
wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 &&
tar xjvf ffmpeg-snapshot.tar.bz2 &&
cd ffmpeg && PKG_CONFIG_PATH="/usr/local/lib/pkgconfig" &&
 ./configure --arch=x86_64 --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 \
--enable-cross-compile \
--extra-cflags="-I/usr/local/include" \
--extra-ldflags="-L/usr/local/lib" \
--prefix="/usr/local" \
--pkg-config-flags="--static" \
--extra-libs="-lpthread -lm" \
--enable-libaom \
--enable-libass \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libmp3lame \
--enable-libopus \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libx265 \
--enable-gpl \
--enable-nonfree 2>&1 | tee "/ffmpeg_compile.txt" &&
make -j$(nproc) 2>&1 | tee -a "/ffmpeg_compile.txt" &&
make install 2>&1 | tee -a "/ffmpeg_compile.txt"

...I get the following output:

    ERROR: aom >= 1.0.0 not found using pkg-config

    If you think configure made a mistake, make sure you are using the latest
    version from Git.  If the latest version fails, report the problem to the
    ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
    Include the log file "ffbuild/config.log" produced by configure as this will help
    solve the problem.
    Makefile:160: /tests/Makefile: No such file or directory
    make: *** No rule to make target '/tests/Makefile'.  Stop.
    Makefile:160: /tests/Makefile: No such file or directory
    make: *** No rule to make target '/tests/Makefile'.  Stop.

libaom has definitely been compiled, and its binaries, libraries and pkg-config files are in the relevant folders. When I skip the libaom package, I get the same error for libass, which was installed via Cygwin's package manager. Could this error possibly be caused by how each package was compiled? Not all of the packages that I compiled from source were compiled with the mingw64 compiler - if they didn't cause any problems, I tended to compile with Cygwin's own GCC. In retrospect, it occurred to me that this may have been what you meant earlier when you said:

So you could sidestep the issue by building your own MinGW-w64/GCC cross-compile environment under Cygwin, and use that instead of the package(s) for them that Cygwin provides. But if you do that, you can't link to any of the MinGW-based dependencies provided by Cygwin (zlib, freetype, libass, or so on), because doing so will cause any program they're linked into to require the same .dlls they do. The only way to prevent that is to build all of it yourself all the way up the chain to avoid contaminating the end-product binaries of x264, FFmpeg, or whatever with needing libgcc-1.dll or libwinpthread-1.dll.

It makes sense after the fact, but it didn't occur to me that when cross-compiling all dependencies must themselves be compiled with the same toolchain. Although libaom itself was one of the packages compiled with MinGW-w64, which is confusing. Then again, I suppose that rule applies to *all* dependencies used by the compiler process, such as those I installed from Cygwin's package repository.

Am I correct in thinking, then, that in order to get a successful MinGW-w64 cross-compilation under Cygwin I will need to either build every dependency it relies on from source specifically with the MinGW-w64 toolchain, or have it rely only on MinGW-w64 variants in Cygwin's package repository? These are the dependencies in question:

apt-cyg install \
autoconf \
automake \
binutils \
bc \ (?)
cmake \
cygport \
doxygen \
mingw64-x86_64-gcc-g++ \
gcc-core \
gcc_g++ \
git \
hg \
libass-devel \
libfreetype-devel \
libmp3lame-devel \
libogg-devel \
libopus-devel \
libSDL2-devel  \
libtheora-devel \
libtool \
libvorbis-devel \
libvpx-devel \
make \
mingw64-x86_64-binutils \
mingw64-x86_64-gcc-core \
mingw64-x86_64-headers \
mingw64-x86_64-runtime \
mingw64-x86_64-winpthreads \
mingw64-x86_64-windows-default-manifest \
nasm \
pkg-config \
texinfo \
wget \
yasm

Or is it perhaps just the libraries that I need to find MinGW-64 variants for?

Or am I entirely jumping the gun here and could this error be entirely unrelated? I also have the config.log if that would help you.

Thank you once again.

[qyot27]

Well,

The --target-os should be just a plain 'mingw32'.

--enable-cross-compile probably shouldn't be used here; I'm not really sure what the use case for it actually is, but I've never had to use it while doing cross-compiles with MinGW-w64.

PKG_CONFIG_PATH in the command above is separated from configure with && rather than being passed to ./configure as a local environment variable; while this may be innocuous (having it as a separate command should have the effect of simply forcing it for the entire environment, until you exit the Cygwin shell), it's generally better practice to make sure that stuff like that is attached to the command it's meant to be paired with.

[Kaos-Industries]

Originally Posted by qyot27

Well,

The --target-os should be just a plain 'mingw32'.

--enable-cross-compile probably shouldn't be used here; I'm not really sure what the use case for it actually is, but I've never had to use it while doing cross-compiles with MinGW-w64.

PKG_CONFIG_PATH in the command above is separated from configure with && rather than being passed to ./configure as a local environment variable; while this may be innocuous (having it as a separate command should have the effect of simply forcing it for the entire environment, until you exit the Cygwin shell), it's generally better practice to make sure that stuff like that is attached to the command it's meant to be paired with.

My bad, the inclusion of the longer target OS value was a mistake that I was experimenting with, I can confirm that the output above was from using mingw32 as a target OS, I'll edit that now.

I'll try removing the --enable--cross-compile flag and putting PKG CONFIG in the right place and then report back. Do you not think the error is a result of using non-minGW-64 depednencies then?

[qyot27]

Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain¹ with either MinGW-w64 or Cygwin, not some with one and some with the other.

¹said dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.

[Kaos-Industries]

Originally Posted by qyot27

Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain¹ with either MinGW-w64 or Cygwin, not some with one and some with the other.

¹said dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.

Here are the last six "blocks" of the config.log. They don't mean anything to me, but maybe you can decode them. Let me know if you need more.

                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
check_mathfunc sinf 1 -lm
test_ld cc -lm
test_cc
BEGIN /tmp/ffconf.s2SqLWqy/test.c
    1	#include <math.h>
    2	float foo(float f, float g) { return sinf(f); }
    3	int main(void){ return (int) foo; }
END /tmp/ffconf.s2SqLWqy/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
/tmp/ffconf.s2SqLWqy/test.c: In function 'main':
/tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 int main(void){ return (int) foo; }
                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
check_mathfunc trunc 1 -lm
test_ld cc -lm
test_cc
BEGIN /tmp/ffconf.s2SqLWqy/test.c
    1	#include <math.h>
    2	float foo(float f, float g) { return trunc(f); }
    3	int main(void){ return (int) foo; }
END /tmp/ffconf.s2SqLWqy/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
/tmp/ffconf.s2SqLWqy/test.c: In function 'main':
/tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 int main(void){ return (int) foo; }
                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
check_mathfunc truncf 1 -lm
test_ld cc -lm
test_cc
BEGIN /tmp/ffconf.s2SqLWqy/test.c
    1	#include <math.h>
    2	float foo(float f, float g) { return truncf(f); }
    3	int main(void){ return (int) foo; }
END /tmp/ffconf.s2SqLWqy/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
/tmp/ffconf.s2SqLWqy/test.c: In function 'main':
/tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 int main(void){ return (int) foo; }
                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
check_complexfunc cabs 1
test_ld cc
test_cc
BEGIN /tmp/ffconf.s2SqLWqy/test.c
    1	#include <complex.h>
    2	#include <math.h>
    3	float foo(complex float f, complex float g) { return cabs(f * I); }
    4	int main(void){ return (int) foo; }
END /tmp/ffconf.s2SqLWqy/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
/tmp/ffconf.s2SqLWqy/test.c: In function 'main':
/tmp/ffconf.s2SqLWqy/test.c:4:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 int main(void){ return (int) foo; }
                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lpthread -lm
check_complexfunc cexp 1
test_ld cc
test_cc
BEGIN /tmp/ffconf.s2SqLWqy/test.c
    1	#include <complex.h>
    2	#include <math.h>
    3	float foo(complex float f, complex float g) { return cexp(f * I); }
    4	int main(void){ return (int) foo; }
END /tmp/ffconf.s2SqLWqy/test.c
x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
/tmp/ffconf.s2SqLWqy/test.c: In function 'main':
/tmp/ffconf.s2SqLWqy/test.c:4:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 int main(void){ return (int) foo; }
                        ^
x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lpthread -lm
require_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
check_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
test_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
false --exists --print-errors aom >= 1.0.0
ERROR: aom >= 1.0.0 not found using pkg-config

In the meantime, I'll see how far I get trying to re-build the libraries with MinGW-W64 and looking up the MinGW-w64 variants for the rest.

[Kaos-Industries]

Originally Posted by nevcairiel

I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.

Originally Posted by Groucho2005

Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.

Thanks for your responses.

How would I build FFmpeg with win32threads? Is it as simple as making sure the compiled FFmpeg is enabled with it, or do all of the dependencies also somehow need the option enabled (although so far I haven't seen anything to indicate they're disabled by default)?

[nevcairiel]

If you are building FFmpeg with a cross-prefix, you need to ensure that either a prefixed pkg-config also exists (which is not typically the case for mingw), or you need to also pass --pkg-config=pkg-config to tell it which pkg-config to use.
It appears the error you are seeing comes from pkg-config not being found, which would be remedied passing the above option.

For win32threads, I would personally recommend to build as many dependencies with it as possible - however, for AOM thats really hard, so I wold skip that, and just do x264/x265 and ffmpeg itself. Its not really required to have dependencies use the same threading model, and they could use pthreads.

[Kaos-Industries]

Originally Posted by nevcairiel

If you are building FFmpeg with a cross-prefix, you need to ensure that either a prefixed pkg-config also exists (which is not typically the case for mingw), or you need to also pass --pkg-config=pkg-config to tell it which pkg-config to use.
It appears the error you are seeing comes from pkg-config not being found, which would be remedied passing the above option.

Thank you, I'll try this.

For win32threads, I would personally recommend to build as many dependencies with it as possible - however, for AOM thats really hard, so I wold skip that, and just do x264/x265 and ffmpeg itself. Its not really required to have dependencies use the same threading model, and they could use pthreads.

How would I do this? The only relevant options in x264's configure script are --disable-win32thread and --disable-thread, the latter of which's description is: disable multithreaded encoding, which to me sounds like it disables both pthreads and win32threads.

x265 has to be configured with CMake, so I'm not even sure how to go about finding what option I need to pass to it in order to enable win32thread. cmake --help returns nothing relevant.

[nevcairiel]

Originally Posted by Kaos-Industries

How would I do this? The only relevant options in x264's configure script are --disable-win32thread and --disable-thread, the latter of which's description is: disable multithreaded encoding, which to me sounds like it disables both pthreads and win32threads.

As far as I can tell, building without --disable-win32thread should be enough to use it.

For x265, I'm not sure, I haven't build that for a while.

[Kaos-Industries]

To update where I am with this, I'm still getting the same error while building FFmpeg, even after compiling or sourcing only MinGW-w64 dependencies, although I have made some progress on the cause:

https://stackoverflow.com/questions/...n-by-configure

Hopefully someone here can figure out what's going wrong here that I can't see and put me out of my misery.

[Kaos-Industries]

Originally Posted by qyot27

Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain¹ with either MinGW-w64 or Cygwin, not some with one and some with the other.

¹said dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.

Okay, so after a lot of testing and digging into directories, I've managed to figure out that the cause is that while pkg-config/configure is able to see all the packages that I compiled from source (located in /usr/bin/local/lib/pkgconfig), it isn't able to see the rest that I installed via Cygwin's package manager - which are located in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig.

So naturally it seemed that all I needed to do was add the latter path to PKG_CONFIG_LIBDIR (which I'm using in place of PKG_CONFIG_PATH because it doesn't include /usr/bin by default and therefore avoids potential conflicts between Cygwin and MinGW-w64 packages).

However, this still doesn't work to compile any of the packages in the mingw prefix folder,

This is the most working version of the command I currently have:

cd /ffmpeg_sources && rm -fr ffmpeg &&
wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 &&
tar xjvf ffmpeg-snapshot.tar.bz2 1> /dev/null && rm -f ffmpeg-snapshot.tar.bz2 && cd ffmpeg &&
export PKG_CONFIG_LIBDIR="/usr/local/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" &&
./configure --arch=x86_64 --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 \
--extra-cflags="-static -I/usr/local/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include" \
--extra-ldflags="-static -L/usr/local/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib" \
--extra-libs="-pthread -lm" \
--prefix="/usr/local" \
--pkg-config="pkg-config" \
--pkg-config-flags="--static" \
--enable-libaom \
--enable-libass \
--enable-libfdk-aac \
--enable-libfreetype \
--enable-libmp3lame \
--enable-libopus \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libx265 \
--enable-gpl \
--enable-nonfree \
--enable-static  \
--disable-shared &&
make -j$(nproc) &&
make install

Adding --sysinclude="/usr/x86_64-w64-mingw32/sys-root/mingw/lib" on its own makes no difference ot it, and adding --sysroot="/usr/x86_64-w64-mingw32/sys-root/mingw" seems to take everything into a completely different direction - instead of the usual pkg-config errors, I get an error that says:

x86_64-w64-mingw32-gcc is unable to create an executable file.

C compiler test failed.

I've made so much progress with this that I feel like I'm way too close to call it quits at this point, so any suggestions as to why pkg-config still refuses to see the packages in the sys-root folder would be appreciated.

[Kaos-Industries]

An update on this: I finally managed to determine that the problem I was running into wasn't what I thought it was at all - that the packages installed through Cygwin's setup/package manager were unable to be seen by pkg-config or PKG_CONFIG_PATH while those I'd built from source could be seen fine. It turns out the only packages that were actually failing to build were three in particular - libvorbis, libass, and libfreetype. I realised this when I started removing --enable-package options and noticed that many of those installed from the Cygwin setup were working fine. I can only assume that the Cygwin version of these particular packages are broken in some way. The plan is now to build these three packages from source, and see whether that solves my issues.

[qyot27]

Running into that was largely why I hadn't responded. The errors being emitted for libass indicated that it wasn't finding the other libraries* libass links against, even though several of them (in their mingw64- variants, of course) were installed. libvorbis only depends on libogg, IIRC. Freetype2 is part of the libass dependency chain, so all the things it needs would be covered by getting all the things libass needs.

*libass missing dependencies:
harfbuzz
glib-2.0
pcre
fontconfig
expat
freetype
png16

Some of those have questionable levels of necessity (harfbuzz, for example, is really only needed if you need to have the ability to render RTL-formatted subtitles, but the downside is that harfbuzz is also what calls in glib2, which I can tell you right now is a nightmare and something I avoided in my build guide because it's so easy to get stuck on; pcre is only needed by either harfbuzz or glib2). The proper order for the libass dependencies are libpng² (which might require zlib¹, so be prepared for that), then from the "Subtitle rendering" section of the guide³, iconv->enca->freetype2->c2man->fribidi->expat->json-c->fontconfig->uchardet->lua (likewise, json-c and uchardet might not actually be necessary for libass, its dependencies, or FFmpeg, but they're there for mpv's sake; lua is definitely just for mpv). c2man is something fribidi needs, and I think that's why I didn't bother with harfbuzz, since it and fribidi have some overlap (IIRC).

Also, libass doesn't have to use fontconfig; it can use Windows' own DirectWrite API, which could mean not having to compile a lot of those dependencies (although at this point I'm not sure which ones). The reason I don't recommend building libass to use DirectWrite is that if you have large (talking several hundred to over a thousand) numbers of fonts installed, you'll have a constant performance hit whenever invoking libass; with fontconfig, so long as you aren't constantly installing fonts, the only hiccup will be the first time it's called, since it has to cache the font list, but fontconfig's cache list is persistent, DirectWrite's is not.

¹https://github.com/qyot27/mpv/blob/e...dious.txt#L391
²https://github.com/qyot27/mpv/blob/e...dious.txt#L772
³https://github.com/qyot27/mpv/blob/e...ious.txt#L1058

[Kaos-Industries]

Originally Posted by qyot27

Running into that was largely why I hadn't responded. The errors being emitted for libass indicated that it wasn't finding the other libraries* libass links against, even though several of them (in their mingw64- variants, of course) were installed. libvorbis only depends on libogg, IIRC. Freetype2 is part of the libass dependency chain, so all the things it needs would be covered by getting all the things libass needs.

*libass missing dependencies:
harfbuzz
glib-2.0
pcre
fontconfig
expat
freetype
png16

Some of those have questionable levels of necessity (harfbuzz, for example, is really only needed if you need to have the ability to render RTL-formatted subtitles, but the downside is that harfbuzz is also what calls in glib2, which I can tell you right now is a nightmare and something I avoided in my build guide because it's so easy to get stuck on; pcre is only needed by either harfbuzz or glib2). The proper order for the libass dependencies are libpng² (which might require zlib¹, so be prepared for that), then from the "Subtitle rendering" section of the guide³, iconv->enca->freetype2->c2man->fribidi->expat->json-c->fontconfig->uchardet->lua (likewise, json-c and uchardet might not actually be necessary for libass, its dependencies, or FFmpeg, but they're there for mpv's sake; lua is definitely just for mpv). c2man is something fribidi needs, and I think that's why I didn't bother with harfbuzz, since it and fribidi have some overlap (IIRC).

Also, libass doesn't have to use fontconfig; it can use Windows' own DirectWrite API, which could mean not having to compile a lot of those dependencies (although at this point I'm not sure which ones). The reason I don't recommend building libass to use DirectWrite is that if you have large (talking several hundred to over a thousand) numbers of fonts installed, you'll have a constant performance hit whenever invoking libass; with fontconfig, so long as you aren't constantly installing fonts, the only hiccup will be the first time it's called, since it has to cache the font list, but fontconfig's cache list is persistent, DirectWrite's is not.

¹https://github.com/qyot27/mpv/blob/e...dious.txt#L391
²https://github.com/qyot27/mpv/blob/e...dious.txt#L772
³https://github.com/qyot27/mpv/blob/e...ious.txt#L1058

Yeah, I came across the glib2 problem a lot while researching this stuff, that and harfbuzz and libass being in some weird dependency loop, so I'd definitely like to avoid the ones I don't need where I can.

So if I'm understanding you correctly, are you saying that I would need to cross-compile each package in those dependency chains from source?

And that those chains would be, in left-to-right order of compilation/install:

libogg > libvorbis

zlib (possibly) > libpng > iconv > enca > freetype2 > c2man > fribidi > expat > fontconfig > json-c (possibly) > uchardet (possibly) > libass

Correct me if I've misunderstood any of the above.

As for fontconfig, I don't have much use for it myself as I've never really seen a need to use FFmpeg's subtitle-generation feature, but part of my being so invested in this project at this point is that I've decided I'll be writing up a guide on how to accomplish this with Cygwin for anyone that comes after (seems a waste not to with the time I've spent on it), and I'm currently weighing up whether the extra packages are worth including that feature for others. Including libass without fontconfig might be a good compromise between making a more complete guide for others and making life easier on myself, but I suppose it ultimately depends on just how much more packages I'll need to compile from source for fontconfig vs libass. How would I find out exactly which dependencies fontconfig needs?