GyanD
commented
1 year ago I use a msys2 / mingw-64 environment with gcc + gnu toolchain.
What's your full msys2 ./configure string? And your CLFAGS / LDFLAGS / pkg config flags?
Closed FrostKiwi closed 1 year ago
GyanD
commented
1 year ago I use a msys2 / mingw-64 environment with gcc + gnu toolchain.
What's your full msys2 ./configure string? And your CLFAGS / LDFLAGS / pkg config flags?
FrostKiwi
commented
1 year ago I use a msys2 / mingw-64 environment with gcc + gnu toolchain.
What's your full msys2 ./configure string? And your CLFAGS / LDFLAGS / pkg config flags?
Ohh, that surprised me! It is also my favorite environment and toolchain on windows. Since my GCC compiled libs instantly resulted in exceptions when called in C# via FFmpeg.AutoGen, I figured there was some kind of underlying cross-compiler in-compatibility. But clearly my assumption was wrong. I took some time now to recompile again and note down every step along the way
I did the whole shebang again.
Msys2 + the MinGW64 environment. GCC 12.2.0. FFmpeg Tag n5.1.2
Compiled with ../configure --prefix=installed --enable-shared --disable-static --disable-programs --disable-vulkan --enable-libx264 --enable-gpl (Trying to stick close to the defaults for now)
@GyanD do you think --target-os=win64 or --arch=x86_64 is required? Do you get libx264 from the package manager or do you compile your own?
This results in the following compile log
Got a successfull compilation. I generated bindings with FFmpeg.AutoGen and the target program failed to accept the .dlls when accessing those dlls with their bindings. They instantly cause an exception, at the very first attempt to get a version number. (But just for reference, the programs etc. are fine, it's just the usage from FFmpeg.AutoGen, that is failing) The details about how it fails with what exception using the above configuration setup is of this post: https://github.com/Ruslan-B/FFmpeg.AutoGen/issues/250#issuecomment-1474868841
So what is the difference to your workflow? dlls attached: FFmpeg dlls.zip
GyanD
commented
1 year ago Try adding --disable-w32threads --disable-autodetect
FrostKiwi
commented
1 year ago --disable-w32threads --disable-autodetect
Configured now with ../configure --prefix=installed --enable-shared --disable-static --disable-programs --disable-vulkan --enable-libx264 --enable-gpl --disable-w32threads --disable-autodetect
Compiled, regenrated Bindings with FFmpeg.AutoGEN.
Unfortunately, instantly throws an exception at ffmpeg.av_version_info(). There is still something different .･ﾟﾟ･(／ω＼)･ﾟﾟ･.
I can't wrap my head around it...
Could you maybe post your configure log? Spcific GCC Version? I really wanna nail down what is so different about it.
GyanD
commented
1 year ago What are your CLFAGS / LDFLAGS / pkg config flags?
FrostKiwi
commented
1 year ago What are your CLFAGS / LDFLAGS / pkg config flags?
I am not adding any myself. But here is everything that is in the environment:
PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
PKG_CONFIG_SYSTEM_INCLUDE_PATH=/mingw64/include
PKG_CONFIG_SYSTEM_LIBRARY_PATH=/mingw64/libMaybe I am creating a conflict by having MSYS2_PATH_TYPE=inherit and thus mixing Windows's and MSYS2's PATHs?
GyanD
commented
1 year ago Does this mean that none of those variables are set?
FrostKiwi
commented
1 year ago Does this mean that none of those variables are set?
I guess that is the case. Aren't those set by the by the configure script via pkg-config automatically? Why would I need to set them myself? I never needed to set those in the past, so I'm confused why this would even be required, unless I'm pulling in custom build libraries...
PS: Compiled withoutMSYS2_PATH_TYPE=inherit, no change
GyanD
commented
1 year ago CFLAGS and LDFLAGS instruct the compiler and linker on how to translate and join generated objects. That can conceivably affect compatibility. Share what CFLAGS and LDFLAGS are after configure has finished and before make.
FrostKiwi
commented
1 year ago y. Share what CFLAGS and LDFLAGS are after configure has finished and before make.
I assume you refer to the *FLAGS in the make configs generated by configure At no point are there *FLAGS in the environment. I grepped the whole build directory after configure, but before make.
The interesting results being CFLAGS:
ffbuild/config.mak:CFLAGS= -std=c11 -fomit-frame-pointer -pthread -DX264_API_IMPORTS -g -Wdeclaration-after-statement -Wall -Wdisabled-
optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wempty-bod
y -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscri
pts -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missi
ng-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitializedCPPFLAGS
ffbuild/config.mak:CPPFLAGS= -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_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPICHOSTCPPFLAGS
ffbuild/config.mak:HOSTCPPFLAGS= -D_ISOC99_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_POSIX_C_SOU
RCE=200112 -D_XOPEN_SOURCE=600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600and LDFLAGS
ffbuild/config.mak:LDFLAGS= -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--warn-common -Wl,-rpath-link=:libpos
tproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutilFigured it out! It was a simple noob mistake, a misunderstanding. I got lazy with debugging due to the cryptic Exceptions not telling the cause. @Ruslan-B figured it out by simply opening the dlls.
Here is where I went wrong: I have compiled C programs with a minimal subset FFmpeg before, but statically + LTO. Now doing it with shared .dlls, I assumed it pulled in all the dependencies into those .dlls. But that was just a wrong assumption. So you have to specifically tell it to pull in libwinpthread, it doesn't happen automatically. Or provide the whole dlls, which is a bit wasteful.
Finally, custom 32bit, minimal, only a couple MBs libavXXX compatible with C# and FFMpeg.AutoGEN <3 Will create a write up in https://github.com/Ruslan-B/FFmpeg.AutoGen/pull/244 for others whishing for custom builds compatible with FFmpeg.AutoGEN and to avoid such noob mistakes.
Hey there :] I am trying to figure out the difference between your Windows FFmpeg builds and my attempt to replicate your build
5.1.2-full_build-www.gyan.dev. Can you give a short two sentence version of how these builds come to be? What compiler, what environment, what version, what ./configure call?This concerns issue https://github.com/Ruslan-B/FFmpeg.AutoGen/issues/250 . I am trying to build ffmpeg, generate C# bindings and use those in a C# program. This works with your
5.1.2-full_build-www.gyan.dev, but not with my builds. I have no issue creating ffmpeg builds and use them in my C programs, but I fail to create a build that works when called via https://github.com/Ruslan-B/FFmpeg.AutoGenThe ultimate goal is to create a 32-bit ffmpeg library, with a very specific minimal set of features, but I fail to replicate even the default, non-customized 64-bit library.
I have tried following https://www.roxlu.com/2019/062/compiling-ffmpeg-with-x264-on-windows-10-using-msvc , https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW#MSys and https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC all with succefully built and working ffmpeg, but failing to get called by the auto generated C# bindings. So what was your workflow for
5.1.2-full_build-www.gyan.dev? I wish to replicate it and go form there to customize a version for my use-case.