Problems when compiling with msvc toolchain and with other libraries.

[David Sterkehus]

Summary of the bug:

1. The library tests can't work with cl.exe.
2. Runtime library specification is necessary even for static builds.

(See last section for details)

How to reproduce:

% vcvarsall.bat
% export LIB="X:\pathto\externlibs\lib;$LIB"
% export INCLUDE="X:\pathto\externlibs\include;$INCLUDE"
# MT, with no msvcrt DLL
% ffmpeg -i input ... output
./configure --toolchain=msvc --enable-gpl --enable-nonfree --enable-nvenc --enable-libvorbis --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libx265 --enable-libxvid --enable-static --disable-shared --disable-debug --extra-cflags="-MD" --extra-cxxflags="-MD" --extra-ldflags="/nodefaultlib:libcmt.lib" --extra-libs="libmp3lame-static.lib libtheora_static.lib libxvidcore.lib zlib.lib libmpghip-static.lib libvorbis_static.lib x265-static.lib libogg_static.lib libx264.lib"
# MD, with msvcrt
./configure --toolchain=msvc --enable-gpl --enable-nonfree --enable-nvenc --enable-libvorbis --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libx265 --enable-libxvid --enable-static --disable-shared --disable-debug --extra-cflags="-MT" --extra-cxxflags="-MT" --extra-ldflags="/nodefaultlib:msvcrt.lib" --extra-libs="libmp3lame-static.lib libtheora_static.lib libxvidcore.lib zlib.lib libmpghip-static.lib libvorbis_static.lib x265-static.lib libogg_static.lib libx264.lib"

MSVC compiles just fine when it compiles just ffmpeg it self. But when it comes to compile with other libraries enabled, it goes into chaos.

1. The library tests when using MSVC toolchain

The script builds test programs for enabled libraries to check if they are available with the given toolchain. For example, to see libmp3lame, it compiles following code:

#include <lame/lame.h>

int main(){
lame_set_VBR_quality();
return 0;
}

specified by configure script line:

enabled libmp3lame        && require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame

The problem is, link.exe somehow doesn't know what to link and complains with error. Yes, the full prototype for the function is:

int lame_set_VBR_quality(lame_global_flags *, float)

Removing these checks(see attachment) solves this problem and the compilation never fails under the circumstance that libraries are properly set in LIB and INCLUDE vars.

2. Runtime library links

MSVC toolchain links what runtime library to use when COMPILE TIME, NOT link time. So /MD and /MT switches are in compiler settings not in linker settings.
If you have to link MT on your program that links ffmpeg-libs, linking ffmpeg-libs compiled with /MD won't work because of the external libraries. Linking will fail. You need to link MT version of ffmpeg-lib for MT programs or DLLs and vice versa.
As you can see on the "How to reproduce" section, you can compile and link MT as mentioned and the other libraries that ffmpeg uses.

If someone could fix these problems, we could use use MSVC to compile ffmepg freely, without using painful mingw toolchains.

[David Sterkehus]

Patch to make configure script to skip library checks.

[Hendrik]

This works just fine if your libraries are named properly, and wouldn't be named something-static.lib, which is not a name configure checks for, and not standard names these libs distribute as usually.

[Hendrik]

Regarding MT and MD, well its a known fact that mixing these can lead to troubles, there is nothing we can do to change how the compiler and linker work, so I'm not sure what you are trying to achieve?

[David Sterkehus]

Yees. But still, "libmpghip.lib" is missing which comes with libmp3lame static build. I compiled Lame with VC, and libmpghip.lib is needed to work with libmp3lame.lib.
Those '--extra-libs' options were merely for my convenience.

And for rumtimes, I wish there could be "--msvc-runtime=msvcrt" and "--msvc-runtime=libcmt". I didn't mean to "mix" them. As I mentioned, you can't link MD linked libraries into MT linked program or DLL. The libraries will conflict(msvcrt.lib and libcmt.lib). I just wanted a ffmpeg.exe that doesn't require VC++ redist to run. With /MD switch on, you can't build one.

Should I make another ticket?

[Hendrik]

MT is the default mode, you shouldn't need to specify anything to get a statically linked dll without vcredist deps.

[David Sterkehus]

Two things, please:

1. "libmpghip.lib" (-lmpghip). It's definite one.
2. linking x265 (not 264)

Wrong example, sorry.
As you know x265 is C++ project, /MD is default config even if ENABLE_SHARED is unchecked on CMake dialog.
Its result IS static, except the runtimes parts linked to mscvrt. Here's the fuzz i've been trying to tell: How do I build /MD linked static ffmpeg-libs? I can't with currnet configure script. "--disable-shared" will make /MD disappear.
The other way around is fine. Everything's statically linked? every library's happy. MD static libraries? ... That's why I wish to have 'runtime spec'.

Does this explain now?
Thanks, by the way, for your replies.

Replying to heleppkes:

MT is the default mode, you shouldn't need to specify anything to get a statically linked dll without vcredist deps.

[Hendrik]

I'm confused, I thought you didn't want vcredist deps, so why would you want /MD static libraries?

We can't "fix" external libraries. You should consult with x265 and ask them how to build a static library with /MT, so that it can be linked with ffmpeg without any problems.

[David Sterkehus]

That was one hell long conversion of "We wont do that"