DebugDLL does not generate import libraries (probably because of missing symbols) about ffmpeg

[JPGygax68]

Additional question: does project_generate have an option to generate code that uses the dynamically linked C/C++ runtimes ?

[Sibras]

There was some old info in the readme about the output dir that I missed, thanks for pointing it out as its fixed now.

The project generator doesnt have an option to change the C runtime lib as it uses the same configuration as the original FFmpeg configure script. Changing it to dynamic can also cause some issues as external dependencies are generally built using the static runtime (projects supplied by SMP you can change but other external ones are outside my control). However its pretty easy to just change it in the project settings if you wish.

As for the import library naming that is something that im open to suggestion on.

Finally as for the subject of the ticket you might want to check your configuration again. Theres obviously something about your setup that is causing issues as I just ran a check on mine and the import library is generated as expected for debug builds.

[Sibras]

By the way the Release builds also generate debug information and although not as complete as a debug build due to optimisations they are still debugable.

[JPGygax68]

Oops, my bad. The import libraries are generated (btw this is on my notebook, which does not have the MSBuild bug), only they go to the bin/ directory, not lib/.

About dynamically linked runtimes: my reason for wanting that is that Qt5 is built like that. Trying to link in your FFmpeg libs causes a deluge of LNK2005 errors. Like you said though, it should be easy to change manually. I think it should be possible to multi-select the projects and change them all at once.

Regarding external libraries using statically linked runtimes, well I'm not sure you're right there. It seems to me there is a surprising number of libraries that use the dynamically linked runtimes by default.

Btw did you ever consider using CMake? From my own limited experience with it, I know that it can be complex and frustrating, but I can't help but think that FFmpeg would benefit greatly if someone managed to pull that off.

[Sibras]

It depends, unfortunately there isnt any kind of standard when it comes to linking the c runtimes so different libs use different things. My comment about statically linking was mostly around libs that can be used as dependencies for creating FFmpeg. Many dependencies are provided by SMP but for those that are not they are mostly statically linked c runtime. Also the default configurations used by the original FFmpeg build scripts uses static aswell. So by default the projects are designed to be compatible with those. Dynamic c runtime is also a pita when you compile with one version of msvc but then try and use them in projects compiled using a different version. Atleast with a c api and static runtime this is often possible.

However as you said you can just select all projects and then multiple configurations and change the code generation options (1min max). Once I get a handle on all possible FFmpeg dependencies and can provide dynamic runtime compatibility ill add in this ability.

[Sibras]

Just a heads up but the import library naming scheme has now also been updated as suggested. So youll have to update any of your projects accordingly (all SMP provided dependencies will need to be updated as well which can be done using the supplied batch file)

[JPGygax68]

Thanks Matt!

[Sibras]

And one more heads up as now all projects use the dynamic c runtime (I also use ffmpeg in Qt programs so have had runtime compatibility issues). So remember to update all the dependencies lib repos. This also adds 2 new repos in libmfx and sdl so if you have previously installed the Intel Media SDK or copied across downloaded sdl devel libs then these are no longer needed and should be removed.

[JPGygax68]

Do I understand this correctly:

1. the dynamic runtimes are optional, right?

2. Intel Media SDK and SDL are no longer required as external dependencies ?

Great work.

On 11/23/2015 12:58 PM, Matthew Oliver wrote:

And one more heads up as now all projects use the dynamic c runtime (I
also use ffmpeg in Qt programs so have had runtime compatibility
issues). So remember to update all the dependencies lib repos. This
also adds 2 new repos in libmfx and sdl so if you have previously
installed the Intel Media SDK or copied across downloaded sdl devel
libs then these are no longer needed and should be removed.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[Sibras]

1. Currently all projects use the dynamic runtime as default. If you want to use the static runtime instead then you just need to change the option in the Visual Studio projects accordingly (you can use any one you wish - same as currently - just that the default is now dynamic)

2. There are now 2 new projects:
   -libmfx which replaces Intel Media SDK and will be used instead. The Intel Media SDK can still remain installed it just wont be used anymore as using libmfx project adds additional benefits such as selecting between dynamic/static runtimes and also using debug builds.
   -sdl which is now a supplied project so it is no longer necessary to download anything from the sdl site. This also allows changing c runtime and generating debug information.

Running the update deps batch file will automatically get these new projects and they are already added to the provided ffmpeg_deps solution file.

If you have any issues/requests then let me know.

[JPGygax68]

This is great. MFX and SDL were the only two things that gave me trouble with my last build (disabled them via config batch).

[JPGygax68]

Unfortunately I now have a different problem - I get a 0x0000007b when trying to launch my EXE.

I noted that, apart from the expected _ff_XXXXXX missing symbols, there are a few more missing symbols that do not fit into the same category: _open, __imp_tempnam and others.

EDIT: so far I've only built the ffmpeg_deps solution. I'm building the ffmpeg.sln right now.

[JPGygax68]

I think I may be going nuts. After changing to static runtimes as we discussed, I'm getting errors like this:
Severity Code Description Project File Line Source Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in libavcodec.lib(api.obj) ffplay D:\Source\ShiftMediaProject\Sources\FFmpeg\SMP\libavcodec.lib(analysis.obj) 1 Build

I have verified half a dozen times that all projects were switched to static runtimes - how can I still be getting MD_DynamicRelease vs MT_StaticRelease mismatches?

[JPGygax68]

I investigated a bit and found something strange. The files that are causing the mismatches apparently come from files with paths like e.g. x265\SMP\obj\Debug_12b\Win32\libx265\yuv.obj - paths that are not contained from the top-level msvc directory.

EDIT: I have no idea why VS would even try to link in those versions of the library, but it's about the only thing that could explain the errors I'm getting.

One more thing worth noting: when I changed the "Runtime Library" setting on the multi-selected projects, the field was initially shown as "". I didn't investigate, but I would have expected it to show "Debug DLL" or "Release DLL" since all projects should use the same setting for a given configuration.

(This problem might also be related to the numerous MSB8012 linker errors I'm getting , e.g. "TargetPath... does not match Library's OutputFile property".)

[Sibras]

OK well make sure that all projects are up to date with the repos (ffmpeg and deps) and then delete the entire msvc output folder as there might be some left over libs with the incorrect runtime settings. Also delete the obj\ folder from any SMP directory in either ffmpeg or one of the dependencies (a search for obj in the parent dir should do). Then try again.

From your description im guessing your building a debugDll build. Have you tried the release builds as they dont have the missing ffmpeg symbols issue so if there are any missing symbols then it makes it a bit clearer.

Also may I ask what you need static runtime versions for? Previously you mentioned a desire for the dynamic runtime version instead to be compatible with Qt (as the projects were previously static). Does this mean you are building both versions?

[JPGygax68]

I'm in the process of starting a fresh download + build.

Yes, unfortunately it is very likely that I'll end up using a wild mix of versions. Qt on one hand, the main project on the other - we're always trying to avoid the DLL runtimes, but with Qt we have no choice.

[JPGygax68]

Still building (fresh download, building "Debug" version of ffmpeg_deps.sln), but I've got at least one error:
18>LINK : fatal error LNK1181: cannot open input file 'libx265_10bd.lib'
I think this was while trying to build libsdl.

EDIT: have not yet tried deleting all the obj dirs. Doing that now.

[JPGygax68]

The Debug build of the deps produces many errors.
The "Debug DLL" only produced two so far (I have to go out right now and let it build, be back in 1 hour):
Severity Code Description Project File Line Error LNK1181 cannot open input file 'libx265_10bd.lib' libx265 D:\Source\ShiftMediaProject\Source\x265\SMP\LINK 1
and
Severity Code Description Project File Line Error LNK1181 cannot open input file 'libx265d.lib' libavcodec D:\Source\ShiftMediaProject\Source\FFmpeg\SMP\LINK 1

[JPGygax68]

All right, some encouring news to report at last. I was able to build the unchanged Release version. I also switch (per multi-select) to statically linked runtimes, and only got 3 errors in the end, saying that some directories already exist, so this might have gone ok too.

The debug builds seem to have problems though. I think that's new, I'm pretty sure I did a debug build yesterday.

[Sibras]

There was a slight regression introduced recently with x265. The project allows x265 to encode either in 8b/10b or 12b. This requires creating 3 different libs and combining them. The bug was that release 10b/12b libs were being created instead of debug ones (hence the missing libx265_10bd). This has been fixed in the x265 repo now.

Tested ffmpeg using debug build and everything runs as expected on my system.

[JPGygax68]

Thanks! But I can confirm now that switching to statically linked runtimes does not work.I've tried it several times now, and taken special care delete the msvc output directory as well as the obj directories.

The symptoms are peculiar: at the end of the build process, VS says it cannot create the "bin" directory, 3 times:

51>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1231,5): error MSB3191: Unable to create directory "D:\Source\ShiftMediaProject\Source\FFmpeg\SMP\..\..\..\msvc\bin\x86". Cannot create "D:\Source\ShiftMediaProject\msvc\bin" because a file or directory with the same name already exists.
50>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1231,5): error MSB3191: Unable to create directory "D:\Source\ShiftMediaProject\Source\FFmpeg\SMP\..\..\..\msvc\bin\x86". Cannot create "D:\Source\ShiftMediaProject\msvc\bin" because a file or directory with the same name already exists.
49>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1231,5): error MSB3191: Unable to create directory "D:\Source\ShiftMediaProject\Source\FFmpeg\SMP\..\..\..\msvc\bin\x86". Cannot create "D:\Source\ShiftMediaProject\msvc\bin" because a file or directory with the same name already exists.

In place of the "bin" subdirectory, "msvc" now contains a 4.5k file named "bin".

When I try to link my project, which is built with statically linked runtimes ("MultiThreaded"), I got a lot of the typical "mismatch" errors (MD_DynamicRelease vs. MT_StaticRelease).
The strange thing is that if I try to reprise the build of FFmpeg_deps, I get a lot of those same errors!

[Sibras]

Have you made sure that the dependency projects are also changed to static runtimes as by default they are dynamic now aswell.

I just tried by selecting all projects in the ffmpeg_deps solution and changing to static runtime. I tried the Debug build same as you and everything built fine and ffmpeg seemed to run without issue. There were no runtime mismatch errors or erroneous 'bin' files.

[JPGygax68]

What does your directory structure look like ? Mine is: a parent directory D:\Source\ShiftMediaProject
which contains a source subdirectory, into which I clone FFmpeg; FFmpeg then gets lots of siblings after I double-click FFmpeg\SMP\project_get_dependencies.bat; finally, the build process creates D:\Source\ShiftMediaProject\msvc.

[JPGygax68]

I did a fresh checkout, runtime switch and build right now, but this time leaving out the programs (ffplay etc.). The build runs to completion with no errors, but when I try to link it with my module, again there are mismatch errors.

[JPGygax68]

I got my setup working. I no longer bothered trying to use statically linked runtimes; instead, I'm now using the DLL builds of FFmpeg (the static libraries take too long to build anyway, because due to the "/FORCE" option the linker cannot work incrementally). And as the FFmpeg libs have a purely C API, the matter of which C runtime is being used does not enter the equation (hopefully) - on my machine; making it work at the customer will be another matter. I will give it another go once I've made some progress with my current issue (RTMP).

[Sibras]

The current directory structure should look something like:

• msvc (OutputDir)
  -> source
• FFmpeg
• ..All other dependency projects..
  So by the sounds of it your structure is correct.

So im stll not sure why youd have errors. As the only change in the recent update was to move from static to dynamic c runtimes as default so if it worked when the projects where static as standard then simply changing them back to static now should result in the exact same thing.

So when you were using the non-DLL builds did building the ffmpeg executable still work without any runtime mismatch errors (assuming you also updated the ffmpeg project to use static runtime)? Since ffmpeg links to the exact same libs as what your project would link to then if it works then so should yours. Also have you made any other alterations to the project files? Are you using the files fomr the repo or have you used project generate to create new ones (in which case what settings were changed)?

[Sibras]

Also is this with VS 2013 or 2015?

[JPGygax68]

All my attempts this past week were done with Visual Studio 2015, Community Edition. I'm going to try a fresh download followed by a non-DLL build right now to make extra sure.

[JPGygax68]

The problem is reproduceable. Here's what I did:

• cloned of FFmpeg (TortoiseGit)
• double-clicked project_get_dependencies.bat in FFmpeg\SMP (cloning proceeds without errors)
• double-clicked ffmpeg_deps.sln (solution loads, no problems are reported)
• multi-selected all the projects (taking care to avoid the folders, and with all project icons closed to avoid selecting non-projects)
• right-click on the selected list of projects (Properties dialog)
• navigated to "C/C++" - "Code Generation"
• for "Runtime Library", selected "Multi-threaded Debug (/MTd)" (was "Multi-threaded Debug DLL (/MDd)" before)
• closed the Properties dialog with Ok
• right-clicked on "ffplay"
• chose "Build"

The build process proceeds without errors up to the point where it complains about not being able to create the bin directory. And indeed, instead of a directory, there is a file by that name in its place, 4'499 bytes big, binary, and containing strings like "META-INF/MANIFEST.MF". Here's a link if you want to look at the content:

https://onedrive.live.com/redir?resid=B14A59372E435016!4528&authkey=!AFCv9fQ9wIRkV5M&ithint=file%2c

Either I'm doing something completely wrong, or Visual Studio is doing something unexpected when using the Properties dialog with a multiple selection.

[JPGygax68]

Forgot to mention: all of the above was done on the "Debug" configuration.

[JPGygax68]

Another observation. Trying to build another configuration consistently fails, and the reason appears to be that somehow, the output directory (msvc) is taking precedence over the source directories as far as include files are concerned.

For example, compilation of lmza will fail because the compiler gets the top-level lzma.h header file from ShiftMediaProject\msvc\include instead of ShiftMediaProject\source\liblzma\src\liblzma\api.

[JPGygax68]

Forgot the last part of the explanation - lzma.h compiled with LZMA_H_INTERNAL defined tries to pull in sub-headers using relative paths, which will fail when lzma.h comes from the wrong directory.

[JPGygax68]

I've pinpointed the problem and can offer a possible solution (for the chosen example lzma, haven't checked the others).

The source of the problem seems to the .\ path at the top of the list of "Additional Include Directories". It seems this is interpreted as being relative to the output directory rather than the project directory as was probably intended.

If you replace that line with $(ProjectDir), you can rebuild the project.

[Sibras]

Not sure why yours is considering "./" relative to the OutDir as all paths should be relative to ProjectDir which is the only behavior I can reproduce (and other projects wouldnt compile at all if the behaved that way). However that did find an issue, all the projects have pre-build events that delete any project headers from the OutputDir so issues like that dont arise. However there was an omission in the lzma project where only the installed header folder was being deleted and not the accompanying lzma.h header. That has been fixed now in the repo now.

[Sibras]

OK I was able to recreate your bug by doing a separate fresh clone of all the repos and then perform the actions that you described. I also got an incorrect aattempt to create a file with the same name as the output directory as well as multiple c runtime clashes when linking.

After looking I was able to determine the issue (which should have occurred to me when the the link issues all had to do with x265 obs). When changing the c runtime you also have to change it for some additional configurations in the x265 project. This is because the project allows you to use a modern feature of x265 which is to encode using either standard 8bit or additionally 10bit or 12bit. The way that x265 does this is that the source files are compiled multiple times each time with different settings, then all these are then combined into the final lib. The project does this by using 2 additional project configurations (for Debug they are the Debug_10bit/Debug_12bit configs) so you have to make sure that you also update the runtime settings for those projects as well.

[Sibras]

As for the erroneous attempt to create a file with the same name as the outdir, I have found that this is a bug in Visual Studio. Once you have made the above fixes (previous post) make sure that you delete any file or folder named 'bin' in the msvc output directory and then try building the project again as now it should work.

[JPGygax68]

Thank you Matt, for your research and fixes.
I can confirm that adjusting the settings of libx265 as you described fixes the mismatches.
As for the liblzma bug, I have no explanation - but I can't reproduce it with the current version, so that's ok too now.
Regarding statically versus dynamically linked runtimes, would it be a lot of work to implement this as an option parameter for project_generate.exe?
Btw I wonder if you're aware of the changes to the C runtimes introduced with Windows 10 and Visual Studio 2015? I found the following blog post while googling for info. It is quite likely that with these changes, we're going to rethink our decision to always use statically linked runtimes.

[Sibras]

It would actually be relatively simple to add a switch to project generate to be able to change the c runtime but that would only effect the project that it generates. All the dependency projects would still have to be manually changed anyway as they are all in different repos which is why i havnt added the option as I figured there was little point (and possibly more source of confusion).

As for the C runtime changes I am aware of these as I had to modify a few things in the projects to get them to work with the new ucrt when I updated them to VS2015. With these new changes there are actually notable performance increases as well as the binary size decreases associated with using the dynamic runtime which is in part why I changed the defaults on the projects to use dynamic crt.

[JPGygax68]

Thanks Matt, and that's good news. Good also to have some solid info about these performance gains, you can never be too sure when all you have is the author's statement...