[Solved] Issue when including ffms2 in x264

[jpsdr]

I have (for a change... :sly:) an issue including ffms2 in x264.
The last time i've built it, everything was fine, but when i tried this WE, it failed.
As there was a few update since my last build, i created a branch from the commit i've successfully build the last time (even if looking at the changes it wasn't probably that), but it also failed.
It wasn't ffmpeg because i've for both used the exact same version...:confused:
The other thing that change also, is that i'm using msys2, and they have updated gcc from 5.3.0 (the one i've used when i successfully build) to 6.1.0.
I've also wanted, out of curiosity, to try with ffmpeg 3.1.1, but it doesn't compile at all with gcc 6.1.0, when it worked with gcc 5.3.0.
The error log generated from the x264 build is here (http://pastebin.com/Cz31V8wK).
There was no error during the build of ffms2.

I need expert advises. From my point of view, it seems to be a compiler issue.
Is 6.1.0 broken ? Do i have to add an option in the compiler for things to work ?

Any help appreciated... :thanks:

[shekh]

I am building x264 fine using media-autobuild_suite
compiler is 6.1.0

[jpsdr]

Don't have issue to build x264, issue is with including ffms2 within x264.

[shekh]

Just checked configure log and it says "ffms:no", sorry.
Anyway I would run autobuild_suite and if it fails report issue to author.

[qyot27]

6.1.0 isn't broken, if anything it may be that you're not being adequately threading-aware with how ffms2 and x264 are configured (or 6.1.0 was built in a similarly thread-mismatched way, but that doesn't mean 6.1.0 is broken).

Those errors are all C++11-related, and ffms2 uses C++11 threading, which requires using a build of GCC built with MinGW's winpthreads implementation (*-gcc-posix under MSys2, in this case). I'm pretty sure you *have* to use x264's pthreads support in this case, leaving it on win32threads will probably result in those kinds of detection errors.

[jpsdr]

Thanks for your tip, it helped. It was a little more complicated than that (i'll update my x264 build tutorial according what i've found).

[jpsdr]

Hmm... Seems to be more tricky than expected.
When i've made a x86 build, ffms2 was included in x264, but not when i've made a x64 build...
Need more tests. One thing for sure, something which used to work is not anymore...

[jpsdr]

Ok, i've made a lot of tests, and i'm still thinking it's a compiler issue.

If i build for x86, everything work fine, whatever i choose (posix or win32threads).
But, if i build for x64, it allways failled, whatever i choose.

Log file for x86 gives :

G:/msys32/local-x264_x86/posix/Original/lib\libffms2.a(filehandle.o):filehandle.cpp:(.text$_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_[__ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_]+0x6d): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
G:/msys32/local-x264_x86/posix/Original/lib\libffms2.a(filehandle.o):filehandle.cpp:(.eh_frame+0x8b): undefined reference to `__gxx_personality_v0'
G:/msys32/local-x264_x86/posix/Original/lib\libffms2.a(filehandle.o):filehandle.cpp:(.eh_frame$_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_+0x13): undefined reference to `__gxx_personality_v0'
collect2.exe: error: ld returned 1 exit status
--------------------------------------------------
Failed program was:
--------------------------------------------------
#include <ffms.h>
int main (void) { FFMS_DestroyVideoSource(0); return 0; }
--------------------------------------------------
checking for FFMS_DestroyVideoSource(0); in ffms.h... yes
checking whether FFMS_VERSION >= ((2 << 24) | (21 << 16) | (0 << 8) | 0) is true... yes
checking for lsmash.h... yes


with finaly :

lavf: yes
ffms: yes
mp4: lsmash


Log file for x64 gives :

G:/msys64/local-x264_x64/posix/t_mod/lib\libffms2.a(filehandle.o):filehandle.cpp:(.text$_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_[_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_]+0x78): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
G:/msys64/local-x264_x64/posix/t_mod/lib\libffms2.a(filehandle.o):filehandle.cpp:(.text$_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_[_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_]+0x86): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
G:/msys64/local-x264_x64/posix/t_mod/lib\libffms2.a(filehandle.o):filehandle.cpp:(.xdata$_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEPKS5_RKS8_+0xc): undefined reference to `__gxx_personality_seh0'
collect2.exe: error: ld returned 1 exit status
--------------------------------------------------
Failed program was:
--------------------------------------------------
#include <ffms.h>
int main (void) { FFMS_DestroyVideoSource(0); return 0; }
--------------------------------------------------
checking for FFMS_DestroyVideoSource(0); in ffms.h... no
Failed commandline was:
--------------------------------------------------
gcc conftest.c -m64 -Wall -I. -I$(SRCPATH) -D_POSIX_C_SOURCE=200112L -std=gnu99 -D_GNU_SOURCE -I/local-x264_x64/posix/t_mod/include -L/local-x264_x64/posix/t_mod/lib -lz -lffms2 -lavformat -liconv -lm -llzma -lbz2 -lz -pthread -lpsapi -ladvapi32 -lshell32 -lavcodec -liconv -lm -llzma -lbz2 -lz -pthread -lpsapi -ladvapi32 -lshell32 -lswscale -lm -lavresample -lm -lavutil -lm -lstdc++ -lavresample -L. -L/local-x264_x64/posix/t_mod/lib -lavformat -liconv -lm -llzma -lbz2 -lz -pthread -lpsapi -ladvapi32 -lshell32 -lavcodec -liconv -lm -llzma -lbz2 -lz -pthread -lpsapi -ladvapi32 -lshell32 -lswscale -lm -lavutil -lm -lshell32 -Wl,--image-base,0x140000000 -m64 -static -Wl,--high-entropy-va -Wl,--dynamicbase,--nxcompat,--tsaware -lpthread -o conftest
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `transaction clone for operator new[](unsigned long long)'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRtWn'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_cow_string_c_strPKv+0x1): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_sso_string_c_strPKv+0x1): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z20_txnal_cow_string_D1Pv+0x5): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z20_txnal_cow_string_D1Pv+0x1e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_addUserCommitAction'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1EPKc+0x2e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRnWt'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x2e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_memcpyRnWt'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x36): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
G:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorD0Ev+0x1a): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
--------------------------------------------------
Failed program was:
--------------------------------------------------
#include <ffms.h>
int main (void) { FFMS_DestroyVideoSource(0); return 0; }
--------------------------------------------------


with finaly :

lavf: yes
ffms: no
mp4: lsmash

[jpsdr]

So, expert advise help asked. Is there any command line i have to add in the x64 to make it work again ? Or is it realy finaly a compiler issue, and i have to wait for a next update in msys2 ?

[filler56789]

Or is it realy finaly a compiler issue, and i have to wait for a next update in msys2 ?

Assuming the problem is in the compiler (GCC 6.1), then (I think) you don't have to "update" MSYS2, just choose an older compiler (5.3 or 5.4). I've read about some issues with GCC 6.1 in the x265 thread, and exactly because of that, I will stick to GCC 5.3 «until I-don't-know-when».

[qyot27]

Assuming the problem is in the compiler (GCC 6.1), then (I think) you don't have to "update" MSYS2, just choose an older compiler (5.3 or 5.4). I've read about some issues with GCC 6.1 in the x265 thread, and exactly because of that, I will stick to GCC 5.3 «until I-don't-know-when».
It was just the stack boundary alignment, IIRC. And that's been fixed now.

[jpsdr]

Ok, so i'll wait msys2 update gcc. Don't know how to roll back, and don't want to bother to... Thanks for your informations.

[filler56789]

Ok, so i'll wait msys2 update gcc. Don't know how to roll back, and don't want to bother to... Thanks for your informations.

But assuming this post may be useful to other people... :)

well, it's not difficult to change the MinGW-w64 compilers used by MSYS2,
all one has to do is change the contents of the mingw* directories.
One may even use version "A.B.C" for 32-bits and version "X.Y.Z" for 64-bits
(and vice-versa).

FWIW — I have built and packed some ``older´´ GCC bundles for MSYS2,
they can be downloaded from one of my Mediafire folders:

https://www.mediafire.com/?3ib29yauv5kdw

[jpsdr]

Thanks. There is older and there is newer.
Should i replace the whole mingw* diretory, or just overwrite in the directory your bundle, to keep the existing files that may not be in the bundle ?

[filler56789]

First of all, backup the current contents of the mingw32 and mingw64 directories, then you can safely empty these directories and re-fill them with older or newer stuff.

By the way: when configuring MSYS2 for the very-first time, it's OK to do anything, except download and install GCC through the MSYS2 shell :sly: Depending on the circumstances, choosing/accepting the «default» options and settings is not the better choice ;)

FWIW (again...) — I use only GCC builds which were compiled to use «pure» pthreads-w32

(many :thanks: to both Zeranoe and nevcairiel).

[jpsdr]

Ok... Woh... You can even choose posix/win32 thread version ! More choice than pacman.
Ok, for now, i'll do everything except gcc with pacman so...
Stupid question. When i build x264, i made a posix and a win32 version. Is the best result compiling the posix version with posix gcc, and win32 with win32 gcc ?

Any specific release advised (sjsj, dwarf,seh) or anyone is good ?

[jpsdr]

I've tried to use the gcc version from the links provided by HolyWu
ffmpeg, lsmash and x264 build properly.
With win32 version, even with komisar patch, ffms2 don't compile.
With posix version, ffms2 compile but link with error, tried 5.4.0 and 6.2.0, dwarf x86 and seh x64 (i haven't tried the sjsj), i've this link error :

G:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/lib/../lib/libiconv.a(localcharset.o):localcharset.c:(.text+0x7): undefined reference to `_imp__GetACP@0'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:651: src/index/ffmsindex.exe] Error 1
CXXLD src/index/ffmsindex.exe
G:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/lib/../lib/libiconv.a(localcharset.o):localcharset.c:(.text+0x7): undefined reference to `_imp__GetACP@0'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:651: src/index/ffmsindex.exe] Error 1

Any idea ? Am i missing something ?

[jpsdr]

Ok, i've tried everything, but only when i put gcc in the pacman, i'm able to build ffms2 until the end. If in the pacman i put everything i used to, except just gcc, and get any of the release and copy it in mingw32 (i've tried all of them), ffms2 don't link with the error i've notified in previous post.
So, finaly, unless someone is able to tell me what i'm missing, return to square on, i'll have to wait that msys2 update its gcc version to solve the issue i have with 64 bits.

[filler56789]

I've tried to use the gcc version from the links provided by HolyWu
ffmpeg, lsmash and x264 build properly.
With win32 version, even with komisar patch, ffms2 don't compile.
With posix version, ffms2 compile but link with error, tried 5.4.0 and 6.2.0, dwarf x86 and seh x64 (i haven't tried the sjsj), i've this link error :
<snip>
Any idea ? Am i missing something ?

AFAIK, those "posix" builds from the MinGW-w64 site use winpthreads, which might explain why they don't solve your problem.

Ok, i've tried everything, but only when i put gcc in the pacman, i'm able to build ffms2 until the end. If in the pacman i put everything i used to, except just gcc, and get any of the release and copy it in mingw32 (i've tried all of them), ffms2 don't link with the error i've notified in previous post.
So, finaly, unless someone is able to tell me what i'm missing, return to square on, i'll have to wait that msys2 update its gcc version to solve the issue i have with 64 bits.

Have you already discussed these issues with the "ffms2 people"? :confused:
I can be wrong, but I still think the actual problem is not in GCC or in MSYS2, but in the current ffms2 code.
To make things clear(er): I suggested older versions of GCC as a possible (and acceptable) workaround, not as an actual solution...

— in the same way I had to compile the latest ffmbc with GCC 4.8.5 and 4.9.4, because cc1(.exe) from GCC 5.x insists in treating some warnings as (unacceptable) errors :scared:

BTW... and FWIW... notice that komisar himself used older versions of GCC for building his latest full-featured releases of x264:

[C:\]
=> k264 -V
x264 0.148.2705kMod 3f5ed56
(libswscale 4.1.100)
(libavformat 57.40.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jun 26 2016, gcc: 4.8.4 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later
and
[C:\]
=> k264x64 -V
x264 0.148.2705kMod 3f5ed56
(libswscale 4.1.100)
(libavformat 57.40.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jun 26 2016, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

[jpsdr]

AFAIK, those "posix" builds from the MinGW-w64 site use winpthreads, which might explain why they don't solve your problem.

This may explain, indeed.


Have you already discussed these issues with the "ffms2 people"? :confused:

I've tried once when i've begun to encounter similar issues, answer was roughly to use a "correct" gcc version.


I can be wrong, but I still think the actual problem is not in GCC or in MSYS2, but in the current ffms2 code.

Maybe, this is out of my field, i'm just trying to keep being able to build my x264 versions.



To make things clear(er): I suggested older versions of GCC as a possible (and acceptable) workaround, not as an actual solution...

Not possible for all. Even if gain is just a little, a little is still interesting when you launch several days of encoding, and i'm making my personnal builds targetting Broadwell CPU, option not avaible on too old versions of gcc.

But guys, for all your advises, informations, links, answers and time spend on them, a big :thanks:

[qyot27]

I hesitated doing so earlier, but to show what I mean when I state that there's not a problem RE:posix threading, I've been maintaining this build guide for FFmpeg and mpv for about 3½ years or so:

https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt

The entire first section is dedicated to building the MinGW-w64/GCC environment. I'll be updating it fairly soon to also include the instructions for a combined 32-bit and 64-bit toolchain.

You'd need to look at building:
zlib, bzip2, xz, iconv, LSMASH, LAVF, FFMS2, x264
in approximately that order (it doesn't really matter what position LSMASH is at, so long as it's prior to x264).

EDIT: I have pushed the beginnings of the 64/32 dual guide. The environment setup and the basic compression libraries are done, but I haven't added 64-bit steps to anything else at this point. After a couple days it'll probably be done, since like always, I'm refreshing the guide as I'm updating with a new version of GCC (I've moved up to 6.2.0 now, which provided the opportunity to revisit this problem).

Also, users of Windows 10 Anniversary Edition that have the Subsystem for Linux installed can *probably* use the guide as-is, since it uses Ubuntu's userland tools. You'll just have to pick either 64-bit (the logical choice, since the Subsystem for Linux is only available on 64-bit Windows 10) or 32-bit.

[qyot27]

Now that I've gotten up to the x264 portion of refreshing the build guide, I can reproduce the behavior on Ubuntu, and I did some digging related to what it's doing (or not doing).

The problem is not the threading. The problem is not MSys2, or MinGW-w64. The problem is a combination of:
64-bit GCC (or G++, rather) being built as static, or trying to link it as static.
Trying to link a program that has to link to libstdc++ (like FFMS2) into a standard C program (like x264).
It may also be an issue inside binutils, or have things MinGW-w64 needs to override/account for if upstream GCC doesn't do anything about it.

It turns out that certain subparts of G++ (introduced in or at least changed in GCC 6.x) use weak references when built for 64-bit, and static linking really doesn't like that. Obviously this needs to be fixed (or rebuild 64-bit GCC with this patch (https://github.com/Alexpux/MINGW-packages/pull/1588)), but it may be avoidable if you use shared libstdc++, with or without FFMS2 being built shared. 32-bit doesn't have this problem because weak references aren't used in that case, apparently.

What this actually does to make x264 fail for 64-bit is that the failure for libstdc++ to be linked against causes FFMS2's pkg-config detection to fail, which spams the config.log with all the rest of the missing libs. If, however, you pass --extra-ldflags="$(PKG_CONFIG_PATH=/usr/x86_64-w64-mingw32/lib/pkgconfig pkg-config --libs --static ffms2) -lstdc++" to x264, it'll cut it down to just the real trouble portion, which are the relocation errors inside of libitm.

EDIT: Confirmed that the patch linked to does fix the problem. 64-bit static FFmpeg->FFMS2->x264 works.

[jpsdr]

Good work. It seems that the patch is in the pipe of MSYS2, so, the next gcc release of MSYS2 should have the issue solved if i'm not mistaking ?

[filler56789]

^
^ @qyot27: many thanks for taking the time to find out the root of the problem :goodpost:
......
It turns out that certain subparts of G++ (introduced in or at least changed in GCC 6.x) use weak references when built for 64-bit, and static linking really doesn't like that. Obviously this needs to be fixed (or rebuild 64-bit GCC with this patch (https://github.com/Alexpux/MINGW-packages/pull/1588)), but it may be avoidable if you use shared libstdc++, with or without FFMS2 being built shared. 32-bit doesn't have this problem because weak references aren't used in that case, apparently.

¿Is there an "easy" :) way to somehow add that patch to the MinGW-w64 build scripts (https://ffmpeg.zeranoe.com/blog/?cat=4) written by Zeranoe? :confused:

[qyot27]

Considering those build scripts are over a year old and build 5.x rather than 6.x, it's not necessary.

If you've grabbed the gcc source itself, it's just a matter of (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L190):
sed -i '79i#define _GLIBCXX_USE_WEAK_REF 0' gcc-6.2.0/libstdc++-v3/config/os/mingw32-w64/os_defines.h

[filler56789]

If you've grabbed the gcc source itself, it's just a matter of (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L190):
sed -i '79i#define _GLIBCXX_USE_WEAK_REF 0' gcc-6.2.0/libstdc++-v3/config/os/mingw32-w64/os_defines.h

:goodpost: ++ :thanks:

Considering those build scripts are over a year old and build 5.x rather than 6.x, it's not necessary.

Well, those scripts can be edited... :cool:

https://files.1f0.de/mingw/scripts/

I myself changed some of them, so that I could build older versions of GCC with up-to-date versions of MinGW-w64 and binutils.

Also, jpsdr wrote that GCC 5.4 is problematic as well :confused:

[qyot27]

Well, those scripts can be edited... :cool:

https://files.1f0.de/mingw/scripts/

I myself changed some of them, so that I could build older versions of GCC with up-to-date versions of MinGW-w64 and binutils.

Also, jpsdr wrote that GCC 5.4 is problematic as well :confused:
Ah, well, it was around the time that there was some sort of change to the directory layouts generated by Zeranoe's scripts that I stopped using them (the environment setup part of the mpv build guide is based on the old version of those scripts before the directory stuff occurred). I think it had something to do with what Fedora's directory layouts wanted? I can't remember, and since I don't use Fedora, I didn't/don't care.

It probably remains to be seen whether the 7.x branch will fix this; apparently the default-setting-for-stack-alignment problem x265 was running into with 6.x is resolved in 7.x, but these are separate issues.

EDIT: And the exact line where that has to be inserted can and probably will change with version updates, so it having to go in at line 79 of os_defines.h is likely specific to 6.2.0. But it really is just that one line inside of that one if block.

[filler56789]

FWIW, I managed to compile a «patched» GCC 6.2... (or at least I hope so),
but I haven't tested it against x264 ++ ffms2.
Avisynth support in x264 has always been sufficient for me :)

http://www.mediafire.com/download/bssfuv59oxdvdsu/GCC620-for-MSYS2-patched.7z

[jpsdr]

MSYS2 just update GCC to 6.2.0-1, but unfortunately, the patch/fix is still not included, because i'm still having a "no" for ffms2 in 64 bits mode for x264... :(

[jpsdr]

MSYS2 quickly update GCC to 6.2.0 Rev2, and issue is fixed in this release.

[filler56789]

MSYS2 quickly update GCC to 6.2.0 Rev2, and issue is fixed in this release.

GREAT! :) :) :)

Now you can add a [SOLVED] tag to this thread :cool:

[Midzuki]

Overdue question:

now that GCC 6.3 is out...

does it work OK for the x264 builds that (try to) include ffms2?

[Midzuki]

Hmmmm.... the "instruction" define _GLIBCXX_USE_WEAK_REF 0 does not appear in the latest os_defines.h file,

so I conclude GCC 6.3 for Windows will have to be ``patched´´ as well.

[jpsdr]

When building ffms2, is there a command/option in the "configure" and/or in the "make" to build ONLY the libraray but not the executables ?
Short story, in a specific case, i have an error during the link of a .exe, stoping everything (and preventing install), but i don't need the .exe, so if there is some option/command preventing in the last step the link of the .exe, the installation may be able to go through the end.

[LoRd_MuldeR]

When building ffms2, is there a command/option in the "configure" and/or in the "make" to build ONLY the libraray but not the executables ?
Short story, in a specific case, i have an error during the link of a .exe, stoping everything (and preventing install), but i don't need the .exe, so if there is some option/command preventing in the last step the link of the .exe, the installation may be able to go through the end.

Makefiles always try to build the dependencies first. Only if all dependencies could be built successfully (or if they were already up-to-date) the target will be built next.

Since the program (.exe) should depend on the library, the Makefile is going to build the library first, and then, if that was successful, the program. So, if it errors out while building the program, the library has already been built before.

Just ignore the error about building the program and grab the desired library file ;)

[jpsdr]

Thanks for the tip... It seems to work, at least x264 is building.

[jpsdr]

I've updated my ffms2 repository, and surprise...:eek: the configure file doesn't exist anymore...
So... How am i suppose to build ffms2 (mainly for x264) now...:confused:

[Midzuki]

I've updated my ffms2 repository, and surprise...:eek: the configure file doesn't exist anymore...
So... How am i suppose to build ffms2 (mainly for x264) now...:confused:

IF it has a configure.ac, THEN use autoreconf for generating the configure script.

[jpsdr]

There is a configure.ac, but when i've tried autoreconf, it failed saying that it could'nt find aclocal...:(
I'm under mingw. I have already pacman -S --needed autoconf, and it says it's up to date. I've tried, just in case pacman -S --needed autoreconf and pacman -S --needed aclocal, but both failed, they doesn't exist.
Any idea by any chance...?

[qyot27]

git checkout c_plugin (and then use the configure there)

You'll have other things to deal with (https://github.com/FFMS/ffms2/issues/304) on the master branch even if you get autotools to play nice - hence the c_plugin suggestion.

[jpsdr]

Solved the aclocal issue, it was in "Automake" package, but now it failled with :

$ autoreconf
autoheader: cannot rename /tmp/aroHcTbT/ahHAkQ71/config.hin as src/config/config.h.in: No such file or directory
autoreconf: /usr/bin/autoheader failed with exit status: 1

I'll try to find in tortoise git how to get the c_plugin.
But if all these updates are too much a pain in the ass for just building ffms2, i'll probably drop the ffms support in my x264 build.

Edit
I've got the c_plugin.
So, your suggestion would be to build from the c_plugin instead of master if it's only for x264 ?

[Midzuki]

UPDATE: running ./autogen.sh does work. The auto-generated ./configure failed only because I don't have zlib (and probably other dependencies as well) installed on my MSYS2 environment.

[jpsdr]

I wanted to try if the new version still worked with ffmpeg 2.8.6, but as i was afraid, it seems it doesn't.
So, i've created an x264 specific branch from before all the big recent updates, which i'll use for the x264 builds.

[qyot27]

Strong note on the c_plugin build method (or maybe in general?): something is wonky with how x264 tries to query ffms2's dependencies for static builds - although perhaps it's specifically in x264 with the traditional set of patches I apply to it, even if I don't recall any of them touching the configure script. You have to explicitly force x264's --extra-ldflags to look for FFMS2 for it to find and link to it:
PKG_CONFIG_PATH=/usr/i686-w64-mingw32/lib/pkgconfig \
./configure \
--prefix=/usr/i686-w64-mingw32 \
--cross-prefix=i686-w64-mingw32- \
--enable-static \
--enable-strip \
--disable-win32thread \
--disable-opencl \
--host=i686-w64-mingw32 \
--extra-ldflags="$(PKG_CONFIG_PATH=/usr/i686-w64-mingw32/lib/pkgconfig pkgconf --libs --static ffms2)"
(as usual for building stuff with MinGW-w64, 'x86_64-w64-mingw32' in the relevant places if building 64-bit)

I wanted to try if the new version still worked with ffmpeg 2.8.6, but as i was afraid, it seems it doesn't.
So, i've created an x264 specific branch from before all the big recent updates, which i'll use for the x264 builds.
Why are you still using a release that's nearly two years old? If you have to use 2.8.x for some dire reason, at least update to the latest one from that series: 2.8.13 (from September 2017).

[jpsdr]

I didn't know 2.8.13 existed, i thought 2.8.x branch halted when 3.0.x begun. I have to use 2.8.x because some pathes of the t_mod version use deprecated functions which doesn't exist anymore on 3.0 (and+), and i don't have the knowledge/skill to modify these patches.
I'll try with 2.8.13, thanks for this information.

[qyot27]

While I don't apply *all* of the patches found on tMod, I do apply many of them (https://github.com/qyot27/x264/commits/patches_silent)* - and there's no issue using FFmpeg-git. Then again, I do try to make sure that the stuff builds and update the patches accordingly if I have to.

*there's currently some issues with the Fade Compensation and Film Grain Optimization patches since the multi-bitdepth update, but those would normally be there too. FGO probably would apply cleanly, IIRC, but its changes depend on some changes in the fadecomp patch.

[jpsdr]

There is issues with at least "avi output" and "audio ouput". Unfortunately, i lack the knowledge to update them, as it needs a knowledge of ffmpeg, and i have total zero knowledge on it.

[qyot27]

Oh. The AVI and audio output patches are ones I leave out on purpose.

[jpsdr]

Well, when i've tried the 3.0, i had an error in the "avi output". After a while, i told to myself that maybe the "avi output" can be dropped, thinking not so much people may use it. So i tried to build without the "avi output", and then it was in the "audio ouput" than an error pops up. I know on the other hand that several people who use my build use the "audio output", so i don't want to drop it.
But, the 8/10 bit merge broke a lot of things, so, for now, i'm cheating.
I've created my own branch from the commit just before the 8/10 bit merge commit, and added manualy the commits afterward i thought interesting, and will not break things (i dropped the lavf updates for exemple). Using this version (https://github.com/jpsdr/x264/tree/x264_Custom), i've been able to keep all the patches with an usual "fetch and rebase". I don't know how long i'll be able to continue, i'll see.