Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th March 2019, 01:54   #1  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Help compiling x264 from source on Cygwin - fatal errors unless AVS is disabled

I'm trying to follow the FFmpeg wiki's guide here to build FFmpeg from source with the most superior codecs it can make use of, like libfdk-aac and libopus:

https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu

I've sorted many of the dependencies to get it to work on Cygwin, and thankfully I didn't need to build most of the packages in that guide from source because they were included in the Cygwin repository, but there are 2 or 3 that are not, including x264 and x265.

So I'm now trying to build x264 from source with the following command:

Code:
cd /ffmpeg_sources && git -C x264 pull 2> /dev/null || git clone --depth 1 https://git.videolan.org/git/x264 
&& cd x264 && PATH="/usr/local/bin:$PATH" PKG_CONFIG_PATH="/ffmpeg_build/lib/pkgconfig" ./configure --prefix="/ffmpeg_build" 
--bindir="/usr/local/bin" --enable-static --enable-pic && PATH="usr/local/bin:$PATH" make -j4 && make install
But at the configure stage of this command, I get a few errors and lots of warnings, but the final error is this one:

Quote:
[Makefile:272: input/avs.o] Error 1
The error immediately before the one above is the HMODULE error here:

https://stackoverflow.com/questions/...e-name-hmodule

And in that question the OP and another answer are trying to follow the very same guide I am while using Cygwin on the same 64-bit Windows 7.

What's the problem here and how can I solve it? The errors go away and the compilation works when I include --disable-avs, but I don't want the version of FFmpeg that I build to come without AVS/Avisynth support.

Thank you in advance.

Last edited by Kaos-Industries; 5th March 2019 at 02:05.
Kaos-Industries is offline   Reply With Quote
Old 7th March 2019, 03:52   #2  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
You're confusing which parts make which input active and for which program. --disable-avs is what x264's configure script uses to disable AviSynth support in the x264 CLI program. It does absolutely nothing to libx264 (which has no input modules), FFmpeg uses libx264, and FFmpeg doesn't care at all whether x264's CLI program has AviSynth enabled. Making AviSynth enabled in FFmpeg is its own option given to FFmpeg's configure script, --enable-avisynth.

The SO answer by Missy tells you exactly what's needed to make x264.exe compile with AviSynth under Cygwin. The problem lies in Cygwin's w32api headers not including wtypes.h in the correct place. The proper fix is that Cygwin's windows.h header needs to include wtypes.h; a stop-gap would be to edit x264's local input/avs.c and insert the wtypes.h include before the include for extras/avisynth_c.h before you compile it. FFmpeg likely will hit the exact same roadblock, making it imperative on Cygwin to fix their header if you want this to be possible without editing stuff yourself.
qyot27 is offline   Reply With Quote
Old 7th March 2019, 20:00   #3  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
You're confusing which parts make which input active and for which program. --disable-avs is what x264's configure script uses to disable AviSynth support in the x264 CLI program. It does absolutely nothing to libx264 (which has no input modules), FFmpeg uses libx264, and FFmpeg doesn't care at all whether x264's CLI program has AviSynth enabled. Making AviSynth enabled in FFmpeg is its own option given to FFmpeg's configure script, --enable-avisynth.

The SO answer by Missy tells you exactly what's needed to make x264.exe compile with AviSynth under Cygwin. The problem lies in Cygwin's w32api headers not including wtypes.h in the correct place. The proper fix is that Cygwin's windows.h header needs to include wtypes.h; a stop-gap would be to edit x264's local input/avs.c and insert the wtypes.h include before the include for extras/avisynth_c.h before you compile it. FFmpeg likely will hit the exact same roadblock, making it imperative on Cygwin to fix their header if you want this to be possible without editing stuff yourself.
Interesting, I suppose I assumed that FFmpeg can only build from the features of the sources that it builds from - my knowledge of compiling isn't too great.

I have tried approaching the Cygwin mailing lists with this but the response I got was that Cygwin wasn't the problem, but maybe coming to them with a more specific solution will change that.

Thanks for the succinct explanation of the problem, a lot of this now falls into place and makes sense, but something still doesn't add up here. I had tried Missy's answer prior, and it resulted in AVS being disabled by default. Sure enough, when I make the necessary change to the windows.h file (which is part of the MinGW Runtime Environment and located in "/usr/include/w32api/") and then run configure and make as before:

Code:
cd /ffmpeg_sources && git -C x264 pull 2> /dev/null || git clone --depth 1 https://git.videolan.org/git/x264 && cd x264 && PATH="/usr/local/bin:$PATH" 
PKG_CONFIG_PATH="/ffmpeg_build/lib/pkgconfig" ./configure --prefix="/ffmpeg_build" --bindir="/usr/local/bin" --enable-static --enable-pic && PATH="usr/local/bin:$PATH" make -j4 && make install
...I get the following output that says AVS has been disabled:

Code:
Cloning into 'x264'...
remote: Counting objects: 258, done.
remote: Compressing objects: 100% (257/257), done.
remote: Total 258 (delta 42), reused 31 (delta 0)
Receiving objects: 100% (258/258), 998.27 KiB | 2.43 MiB/s, done.
Resolving deltas: 100% (42/42), done.
.git        config.guess  doc        filters   tools       x264cli.h
.gitignore  config.sub    encoder    input     version.sh  x264dll.c
AUTHORS     configure     example.c  Makefile  x264.c      x264res.rc
common      COPYING       extras     output    x264.h
platform:      X86_64
byte order:    little-endian
system:        CYGWIN
cli:           yes
libx264:       internal
shared:        no
static:        yes
asm:           yes
interlaced:    yes
avs:           no
lavf:          no
ffms:          no
mp4:           no
gpl:           yes
thread:        posix
opencl:        no
filters:       crop select_every
lto:           no
debug:         no
gprof:         no
strip:         no
PIC:           yes
bit depth:     all
chroma format: all
In other words, including wtypes.h seems to have the same effect as doing configure --disable-avs, and that's why the build then goes on to complete successfully. Any idea why including wtypes.h goes ahead and disables AVS/Avisynth anyway?

Last edited by Kaos-Industries; 7th March 2019 at 20:58.
Kaos-Industries is offline   Reply With Quote
Old 7th March 2019, 20:54   #4  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 844
Before qyot27 chimes in again, I have a question:

do you really have to use Cygwin?

Why not use MSYS2?
filler56789 is offline   Reply With Quote
Old 7th March 2019, 21:24   #5  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by filler56789 View Post
Before qyot27 chimes in again, I have a question:

do you really have to use Cygwin?

Why not use MSYS2?
MSYS creates its own ecosystem isolated from the rest of the system. I already use Cygwin on Windows 7 and have for the last two years to good results. In fact, I already had a Windows binary installation of FFmpeg that Cygwin could also make use of, and did a lot of editing with that.

I'm building from source to get a build of FFmpeg that comes with the best codecs FFmpeg can make use of, such as lib_fdkaac and libopus, and one that's integrated into the rest of the Cygwin ecosystem unlike MSYS would be.
Kaos-Industries is offline   Reply With Quote
Old 7th March 2019, 23:55   #6  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 458
Did you try the media autobuild suite? ( https://github.com/jb-alvarado/media-autobuild_suite )
It does exactly what you want but with MSYS. You just configure what stuff you want in your ffmpeg build and it downloads, patches and compiles everything for you. Including its own independant MSYS environment.
__________________
x264 full help - x264 --fullhelp r2345
Cuttermaran HCEnc provider - Support for HCEnc in Cuttermaran
DualDVDRB - Dual core support for DVD-RB free
Rumbah is offline   Reply With Quote
Old 8th March 2019, 01:32   #7  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by Rumbah View Post
Did you try the media autobuild suite? ( https://github.com/jb-alvarado/media-autobuild_suite )
It does exactly what you want but with MSYS. You just configure what stuff you want in your ffmpeg build and it downloads, patches and compiles everything for you. Including its own independant MSYS environment.
See the post directly above yours for why that "independent MSYS environment" is the opposite of what I'm looking for. And yes, I have tried the Media Autobuild Suite, it's an even worse solution than MSYS on its own considering the bloat included in it and how long it takes to install.
Kaos-Industries is offline   Reply With Quote
Old 8th March 2019, 03:12   #8  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
Quote:
Originally Posted by Kaos-Industries View Post
In other words, including wtypes.h seems to have the same effect as doing configure --disable-avs, and that's why the build then goes on to complete successfully. Any idea why including wtypes.h goes ahead and disables AVS/Avisynth anyway?
What's happening is that throwing wtypes.h into windows.h like that breaks the configure script's ability to correctly check for LoadLibraryW, which is what allows AviSynth to interface with x264.exe in the first place. The check fails, so it cannot enable AviSynth input.

Compare to MinGW-w64, where HMODULE is correctly enabled without wtypes.h being placed in windows.h or input/avs.c or checked for in the configure script. There's probably some place subtly different between MinGW-w64's and Cygwin's headers where wtypes.h does get included that explains this, but I wouldn't know exactly where.

Quote:
Originally Posted by Kaos-Industries View Post
MSYS creates its own ecosystem isolated from the rest of the system. I already use Cygwin on Windows 7 and have for the last two years to good results. In fact, I already had a Windows binary installation of FFmpeg that Cygwin could also make use of, and did a lot of editing with that.

I'm building from source to get a build of FFmpeg that comes with the best codecs FFmpeg can make use of, such as lib_fdkaac and libopus, and one that's integrated into the rest of the Cygwin ecosystem unlike MSYS would be.
That just sounds like path issues as it relates to installed defaults. Cygwin inherits the value of Windows' %PATH% variable by default; MSys2 doesn't by default, but that doesn't mean you can't tell it to do so. Just add the following block into the mingw32.ini, mingw64.ini, or msys.ini config files:
Code:
CHERE_INVOKING=1
MSYS2_PATH_TYPE=inherit
MSYSTEM=MINGW32
(MSYSTEM=MINGW64 for mingw64.ini, MSYSTEM=MSYS for msys.ini)

The reverse, accessing stuff installed to MSys' FHS in a normal Windows cmd.exe session, is just a matter of adding the Windows-style location of MSys' /usr/bin and /usr/local/bin to Windows' %PATH% variable. The same thing is true of Cygwin, and Cygwin's /usr/bin and /usr/local/bin.


Of course, most of that is inconsequential to the immediate discussion (aside from pacman, that's so much nicer to use than Cygwin's package management system, or that MSys2 has newer versions of GCC and MinGW-w64 than Cygwin does, or at least newer than some mirrors for Cygwin do), since Cygwin allows you to install MinGW-w64 and cross-compile such that these issues with HMODULE and wtypes.h would be moot. MinGW-w64 doesn't have that issue the way Cygwin's w32api system base does.

Going out on a limb, however, if you want the most recent stable versions of GCC and MinGW-w64, the steps for setting up a cross-environment on Linux probably map to Cygwin without much hassle (apart from figuring out the right package equivalents for the apt-get commands, using checkinstall at any point, and omitting Wine):
https://github.com/qyot27/mpv/blob/e...gw-tedious.txt

(despite what the note says, --disable-lto does not cause a build error if you don't kill the GCC build process and try to reconfigure it without cleaning/deleting the temp files first; and --disable-lto is necessary to avoid the binutils 'too many file descriptors' issue that does hit FFmpeg in particular)

Last edited by qyot27; 8th March 2019 at 03:15.
qyot27 is offline   Reply With Quote
Old 10th March 2019, 00:58   #9  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
What's happening is that throwing wtypes.h into windows.h like that breaks the configure script's ability to correctly check for LoadLibraryW, which is what allows AviSynth to interface with x264.exe in the first place. The check fails, so it cannot enable AviSynth input.

Compare to MinGW-w64, where HMODULE is correctly enabled without wtypes.h being placed in windows.h or input/avs.c or checked for in the configure script. There's probably some place subtly different between MinGW-w64's and Cygwin's headers where wtypes.h does get included that explains this, but I wouldn't know exactly where.
So is there nothing actually *wrong* per se with Cygwin's implementation? Is it intended behaviour to behave the way it does? I'm wondering how likely it is be able to get a fix implemented via the Mailing List if from their POV there's nothing to fix.

Quote:

That just sounds like path issues as it relates to installed defaults. Cygwin inherits the value of Windows' %PATH% variable by default; MSys2 doesn't by default, but that doesn't mean you can't tell it to do so. Just add the following block into the mingw32.ini, mingw64.ini, or msys.ini config files:
Code:
CHERE_INVOKING=1
MSYS2_PATH_TYPE=inherit
MSYSTEM=MINGW32
(MSYSTEM=MINGW64 for mingw64.ini, MSYSTEM=MSYS for msys.ini)

The reverse, accessing stuff installed to MSys' FHS in a normal Windows cmd.exe session, is just a matter of adding the Windows-style location of MSys' /usr/bin and /usr/local/bin to Windows' %PATH% variable. The same thing is true of Cygwin, and Cygwin's /usr/bin and /usr/local/bin.
Definitely not path issues, when i say ecosystem, I'm referring to the installation paths. I'd rather add some packages to Cygwin or use a Windows cross-compiled binary as I normally would rather than go through the hassle of setting up a standalone MSYS environment just for the purpose of using FFmpeg.

Quote:
Of course, most of that is inconsequential to the immediate discussion (aside from pacman, that's so much nicer to use than Cygwin's package management system, or that MSys2 has newer versions of GCC and MinGW-w64 than Cygwin does, or at least newer than some mirrors for Cygwin do), since Cygwin allows you to install MinGW-w64 and cross-compile such that these issues with HMODULE and wtypes.h would be moot. MinGW-w64 doesn't have that issue the way Cygwin's w32api system base does.

Going out on a limb, however, if you want the most recent stable versions of GCC and MinGW-w64, the steps for setting up a cross-environment on Linux probably map to Cygwin without much hassle (apart from figuring out the right package equivalents for the apt-get commands, using checkinstall at any point, and omitting Wine):
https://github.com/qyot27/mpv/blob/e...gw-tedious.txt

(despite what the note says, --disable-lto does not cause a build error if you don't kill the GCC build process and try to reconfigure it without cleaning/deleting the temp files first; and --disable-lto is necessary to avoid the binutils 'too many file descriptors' issue that does hit FFmpeg in particular)
I use the apt-cyg package manager, which does the job pretty well thankfully and usually prevents needing to go through the Cygwin installer.

Regarding setting up MinGW-W64 via Cygwin, that was actually was what I had been trying to accomplish the day after I posted this thread. The furthest I got to was running this command:

Code:
cd /ffmpeg_sources && git -C x264 pull 2> /dev/null || git clone --depth 1 https://git.videolan.org/git/x264 && cd x264 && PATH="/usr/local/bin:$PATH" 
PKG_CONFIG_PATH="/ffmpeg_build/lib/pkgconfig" ./configure --prefix="/ffmpeg_build" --host=x86_64-w64-mingw32 --bindir="/usr/local/bin" --enable-static --enable-pic
Although it does do away with the initial problems involving AVS and gets me a lot further through the make command, the output has hundreds of errors and warnings, and the point at which it fails is this:

Code:
hell32 -Wl,--image-base,0x140000000 -m64   -Wl,--high-entropy-va -Wl,--dynamicbase,--nxcompat,--tsaware
libx264.a(win32thread.o):win32thread.c:(.text+0x60): undefined reference to `_beginthreadex'
libx264.a(win32thread.o):win32thread.c:(.text+0x60): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_beginthreadex'
collect2: error: ld returned 1 exit status
make: *** [Makefile:258: x264.exe] Error 1
I also tried several of the possible solutions I found when Googling for the errors, including using --extra-cflags="-mcmodel=medium" and --extra-cflags="-mcmodel=large", but none worked.

Last edited by Kaos-Industries; 10th March 2019 at 01:37.
Kaos-Industries is offline   Reply With Quote
Old 10th March 2019, 03:00   #10  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
Quote:
Originally Posted by Kaos-Industries View Post
So is there nothing actually *wrong* per se with Cygwin's implementation? Is it intended behaviour to behave the way it does? I'm wondering how likely it is be able to get a fix implemented via the Mailing List if from their POV there's nothing to fix.
It's hard to say.

Quote:
Definitely not path issues, when i say ecosystem, I'm referring to the installation paths. I'd rather add some packages to Cygwin or use a Windows cross-compiled binary as I normally would rather than go through the hassle of setting up a standalone MSYS environment just for the purpose of using FFmpeg.
You wouldn't need to. Almost nobody compiles things for MSys (requiring msys1.dll to be on the PATH), they only use MSys as a means to use MinGW-w64, which is why I mentioned that it was largely moot if you were already using MinGW-w64 through Cygwin.

Quote:
I use the apt-cyg package manager, which does the job pretty well thankfully and usually prevents needing to go through the Cygwin installer.

Regarding setting up MinGW-W64 via Cygwin, that was actually was what I had been trying to accomplish the day after I posted this thread. The furthest I got to was running this command:

Code:
cd /ffmpeg_sources && git -C x264 pull 2> /dev/null || git clone --depth 1 https://git.videolan.org/git/x264 && cd x264 && PATH="/usr/local/bin:$PATH" 
PKG_CONFIG_PATH="/ffmpeg_build/lib/pkgconfig" ./configure --prefix="/ffmpeg_build" --host=x86_64-w64-mingw32 --bindir="/usr/local/bin" --enable-static --enable-pic
Although it does do away with the initial problems involving AVS and gets me a lot further through the make command, the output has hundreds of errors and warnings, and the point at which it fails is this:

Code:
hell32 -Wl,--image-base,0x140000000 -m64   -Wl,--high-entropy-va -Wl,--dynamicbase,--nxcompat,--tsaware
libx264.a(win32thread.o):win32thread.c:(.text+0x60): undefined reference to `_beginthreadex'
libx264.a(win32thread.o):win32thread.c:(.text+0x60): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_beginthreadex'
collect2: error: ld returned 1 exit status
make: *** [Makefile:258: x264.exe] Error 1
I also tried several of the possible solutions I found when Googling for the errors, including using --extra-cflags="-mcmodel=medium" and --extra-cflags="-mcmodel=large", but none worked.
More than likely, Cygwin's build of MinGW-w64/GCC only supports pthreads; you're telling it to build with win32threads. You're also not specifying --cross-prefix, so it's questionable what the compiler thinks it's supposed to do.

Assuming you've installed the mingw64-amd64-gcc-g++ package:
Code:
cd x264 && \
mkdir -p x264-build/amd64 && \
../../configure --prefix=$HOME/x264_build --cross-prefix=x86_64-w64-mingw32- --enable-static --enable-strip --disable-win32thread --disable-opencl --host=x86_64-w64-mingw32 && \
make -j$(nproc) && \
make install
qyot27 is offline   Reply With Quote
Old 11th March 2019, 19:17   #11  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
More than likely, Cygwin's build of MinGW-w64/GCC only supports pthreads; you're telling it to build with win32threads. You're also not specifying --cross-prefix, so it's questionable what the compiler thinks it's supposed to do.
Interesting, I'd tried using both --disable-win32threads and --disable-thread, and had also come across --host, --build, and --target, but I'd never once come across --cross-prefix. So far this gives me the most complete build I have so far, although there are still problems.

Quote:
Assuming you've installed the mingw64-amd64-gcc-g++ package:
Code:
cd x264 && \
mkdir -p x264-build/amd64 && \
../../configure --prefix=$HOME/x264_build --cross-prefix=x86_64-w64-mingw32- --enable-static --enable-strip --disable-win32thread --disable-opencl --host=x86_64-w64-mingw32 && \
make -j$(nproc) && \
make install
There are no packages with amd64 in the Cygwin package manager - the relevant packages I have are mingw64-x86_64-gcc-core and its required dependencies, which include the headers for it, the runtime and the package mingw64-x86_64-winpthreads, as well as the libgcc1 and libgccpp1 libraries.

When I run your command, I get a successful build of the x264 binary with no errors at all, but when I execute it, I get an error that says:

Quote:
C:/cygwin64/usr/local/bin/x264.exe: error while loading shared libraries: libwinpthread-1.dll: cannot open shared object file: No such file or directory
However, when I replace --disable-win32thread in configure with --disable-thread, I get a fully working binary. Does disable-thread completely disable multithreading support, and if so, is there a way to make this work with just --disable-win32threads?

Also, as an aside and for my own working knowledge, I noticed that the --open-cl option does not seem to make a difference to whether the program compiles successfully or not - adding --disable-thread but leaving out --disable-opencl compiles a working binary. Is it needed or recommended here?

Last edited by Kaos-Industries; 11th March 2019 at 19:20.
Kaos-Industries is offline   Reply With Quote
Old 11th March 2019, 20:44   #12  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
Whoops, my mind tends to substitute 'amd64' into triplets, since i686 or amd64 are how I have my packages named when I cross-compile them on Ubuntu.

I believe the correct package for winpthreads is mingw64-x86_64-winpthreads. I'm not sure why that wouldn't have already been installed and be available for you to use, though.

Whether to enable the OpenCL module is just personal preference. I've never bothered trying to use the feature, and it relies on having hardware that can use OpenCL (most likely, your graphics card - not sure about how well it works with Intel's or AMD's integrated graphics stacks in the processors that come with them).

Last edited by qyot27; 11th March 2019 at 21:04.
qyot27 is offline   Reply With Quote
Old 11th March 2019, 21:06   #13  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
Whoops, my mind tends to substitute 'amd64' into triplets, since i686 or amd64 are how I have my packages named when I cross-compile them on Ubuntu.

I believe the correct package for winpthreads is mingw64-x86_64-winpthreads. I'm not sure why that wouldn't have already been installed and be available for you to use, though.
It is installed and a required dependency, as mentioned in my post.

I did come across this:

https://github.com/HaxeFoundation/hxcpp/issues/339

...and judging by the last post in it I assume this means there's (still) no way to create a static version of any package with MinGW-64?

If not, then the answer seems to be that I'll just have to add "\usr\x86_64-w64-mingw32\sys-root\mingw\bin" to my PATH, which I wanted to avoid but that doesn't seem possible anymore.

Last edited by Kaos-Industries; 11th March 2019 at 21:19.
Kaos-Industries is offline   Reply With Quote
Old 11th March 2019, 21:39   #14  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
It's completely possible to do fully static packages. The build guide I maintain (and linked above) for cross-compiling for Windows from an Ubuntu host goes through the steps to enforce it through the cross-compile environment. The resulting builds don't require any external DLLs aside from ones they immediately require from their dependencies (like libbluray using the DLLs of libaacs and libbdplus rather than statically linking against them), or the basic Windows equivalents that building with MinGW is meant to mimic (msvcrt, etc.).

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.

If that's too daunting and you're fine mixing the results of two GCC environments, an alternate solution to adding that directory to the PATH is to use LinkShellExtension, and simply create symbolic links of libwinpthread-1.dll and libgcc-1.dll in a location that's already on the PATH.
qyot27 is offline   Reply With Quote
Old 11th March 2019, 22:59   #15  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
It's completely possible to do fully static packages. The build guide I maintain (and linked above) for cross-compiling for Windows from an Ubuntu host goes through the steps to enforce it through the cross-compile environment. The resulting builds don't require any external DLLs aside from ones they immediately require from their dependencies (like libbluray using the DLLs of libaacs and libbdplus rather than statically linking against them), or the basic Windows equivalents that building with MinGW is meant to mimic (msvcrt, etc.).

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.

If that's too daunting and you're fine mixing the results of two GCC environments, an alternate solution to adding that directory to the PATH is to use LinkShellExtension, and simply create symbolic links of libwinpthread-1.dll and libgcc-1.dll in a location that's already on the PATH.
What if I did add it to the PATH for this current package? Would I still be able to compile an "end-product binary" of FFmpeg that was static? Or is there pretty much no way with my current Cygwin/MinGW setup (i.e. without compiling all the dependencies from source) to compile binaries that don't rely on those DLLs?

Last edited by Kaos-Industries; 12th March 2019 at 00:19.
Kaos-Industries is offline   Reply With Quote
Old 12th March 2019, 00:36   #16  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
Keeping in mind that I don't mess with the normal/shared GCC builds, and therefore am just taking a stab in the dark, you *might* be able to do it if you pass -static to LDFLAGS/--extra-ldflags. The packages do seem to have the relevant static libgcc.a and libwinpthread.a installed to the right /lib directories.
qyot27 is offline   Reply With Quote
Old 12th March 2019, 01:47   #17  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27
Keeping in mind that I don't mess with the normal/shared GCC builds, and therefore am just taking a stab in the dark, you *might* be able to do it if you pass -static to LDFLAGS/--extra-ldflags. The packages do seem to have the relevant static libgcc.a and libwinpthread.a installed to the right /lib directories.
Success! I managed to get a fully static and working binary of x264, and without adding anything to the PATH or passing extra flags to the linker. It turns out --disable-win32thread was getting in my way, and simply removing it works. This essentially means that the only thing I was missing was --cross-prefix, which I wasn't even aware I needed as I'd never come across it in my exhaustive searching despite how crucial it evidently seems to be for cross-compiling.

Last edited by Kaos-Industries; 12th March 2019 at 02:12.
Kaos-Industries is offline   Reply With Quote
Old 12th March 2019, 02:05   #18  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Actually, now that I think about it, I remembered something I came across during my research for all this:

Quote:
If you’ve come across --enable-win32thread, you’ll know the name is sweet but don’t ever use it!! (Not that you care.) You’ll lose multi-threading capability since we are not cross-compiling for windows; we are compiling for Cygwin.
(From https://koohiimaster.wordpress.com/2...thout-mingw32/)

I wonder if that applies here and the x264 binary I've built is crippled to work in single-threaded mode. Is there any way to determine whether a binary comes with multithreading support? If not, would anyone happen to have a sample AVS file I can easily use with x264 to test that it has multithreading support?

Last edited by Kaos-Industries; 12th March 2019 at 02:12.
Kaos-Industries is offline   Reply With Quote
Old 12th March 2019, 02:24   #19  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,022
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.
qyot27 is offline   Reply With Quote
Old 12th March 2019, 02:42   #20  |  Link
Kaos-Industries
Registered User
 
Join Date: Feb 2019
Posts: 20
Quote:
Originally Posted by qyot27 View Post
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.
Perfect, so I suppose I have my solution? Thanks a lot for your help throughout this thread, it's been really appreciated. Time to get to work compiling everything else I need and then FFmpeg itself, here's to hoping it'll go a lot more smoothly.
Kaos-Industries is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 02:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.