Cannot build libavutils: LNK2001 "unresolved external symbol avpriv_emms_yasm" about ffmpeg

[Sibras]

You cant change from yasm to masm as they do not support the same things (completely different assembly syntax). yasm is required to compile all the assembly files and if they are not correctly compiled then obviously you will have missing symbols due to missing code.

So your errors are because yasm hasnt been setup correctly. Make sure you follow the readme exactly. You can also get more detailed error information by cut and pasting the failed yasm command into a visual studio developer command prompt.

[JPGygax68]

Got sidetracked, sorry for the delay, I copy-pasted one of the yasm commands and it says "vsyasm: FATAL: could not load standard modules".

[JPGygax68]

Update: I found out that I had an extra vsyasm.exe in my path. I removed it, and now I get a different error:
Error 1 error MSB3721: The command "vsyasm -Xvc -f win32 -g cv8 -i "..\\" -i ".\\" -i "..\libavcodec" -o "D:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\SMP\\obj\DebugDLL\Win32\libavutil\\" -P "config.asm" -rnasm -pnasm "d:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\libavutil\x86\cpuid.asm"" exited with code 1. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\vsyasm.targets 45 5 libavutil

[JPGygax68]

I went through the README again, but still no success. I noticed two things:

1. The project seems to use both vsyasm.exe (without a path) and "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\"vsyasm.exe. It does NOT try the MSBuild path, so I copied the yasm files to the VC\bindirectory.

2. Some build commands work when I paste them into the command line, but still generate "exited with code 1" during the build. Example:

"D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\"vsyasm.exe -Xvc -f win32 -g cv8 -i "..\\" -i ".\\" -i "..\libavcodec" -o "D:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\SMP\\obj\DebugDLL\Win32\libavutil\\" -P "config.asm" -rnasm -pnasm  "D:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\libavutil\x86\cpuid.asm"

[Sibras]

I recently noticed an issue with Visual Studio changing the PATH variable in unusual ways and not searching the correct directories for yasm. The solution I found (which i put in the readme last week) was to put the only copy of vsyasm exe into:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools" (for VS 2015 replace the 12.0 with 14.0).

This should ensure that VS always detects vsyasm and that if the command executes in the VS command prompt then it will also work from within the project.

[JPGygax68]

I'm sorry, but I've tried your suggestion and it made no difference. I've also tried every variation I could think of; at this time, I've got copies of the 4 vsyasm files (with the correct config) in every directory that MSBuild / Visual Studio might want to access. Nothing I try makes the slightest difference.

I've also tried this suggestion, with no results whatsoever.

I've noticed that Visual Studio, after I had applied your suggestion, would still try to launch vsyasm from the wrong directory. Perhaps a reboot would fix that, I'm gonna try that next.

The situation at present though is, again, that the command works from the command line but not during build.

This is frustrating as hell, especially considering all the hard work you've put into this (I realize of course none of this is your fault), and even more so considering that it used to work here.

In fact, this problem seems to have appeared after I installed Visual Studio 2015 (without removing 2013, which I'm using with FFMPEG). I then de-installed 2015, tried again - no improvement -, then re-installed it, and have been stuck ever since.

[JPGygax68]

I've once again removed all the extra copies of yasm as per your new readme, then rebooted. And there's definitely something weird going on, because the build still tries to access yasm with a Visual Studio path: "D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\"vsyasm.exe.

Do you know where to fix that ?

[Sibras]

Installing 2015 was when I noticed that the path was not being set correctly on occasion as well so there appears to be an oddity in 2015. A fresh install of VS 2015 worked for me out of the box however I did get issues with the Path once I installed the intel compiler.

OK so if you have both 2013 and 2015 installed then try this:

1. Remove ALL previous vsyasm files.
2. Copy (preferably a fresh copy) the xml, targets and props files to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations" for VS 2013 AND to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations" for 2015.
3. Copy vsyasm.exe to "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools" for VS 2013 AND to "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools" for 2015.
4. Update vsyasm props files (both) as indicated in part 3 and 4 of the readme.
5. Reset the git tree (or regenerate the FFmpeg projects files) so they're fresh copies (in case the build customizations referenced in the project files got messed up)

Thats the configuration that i use and was what was required to get VS 2015 to work. So try that.
I fit still doesnt work then you can check the paths that VS is looking for vsyasm.exe by adding the following line to a projects pre-build event "echo %PATH%" which will print the path to the output at the start of a build. Also if its still there then where is the reference to "VC\bin"vsyasm.exe" appearing?

[JPGygax68]

No luck with the copied yasm files.

I'm appending the content of %PATH% as seen by MSBuild at the end of this reply, but I don't think the problem lies there, because I went to the Property Manager and removed the "Inherit" checkbox on the Executable paths. This would lead to MSBuild no longer finding the linker, but the assembler error message stayed the same.

Here is the yasm command line again (which still works from the command line):

"D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vsyasm.exe" -Xvc -f win32 -g cv8 -i "..\\" -i ".\\" -i "..\libavcodec" -o "D:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\SMP\\obj\DebugDLL\Win32\libavutil\\" -P "config.asm" -rnasm -pnasm "D:\SourceLibs\ShiftMediaProject\Sources\FFmpeg\libavutil\x86\cpuid.asm"

One thing is odd, there are several double backslashes there. I have no idea where they come from, could they cause the problem?

---

PATH:
D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools;D:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\bin;D:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\tools;D:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\ide;C:\Program Files (x86)\HTML Help Workshop;;C:\Program Files (x86)\MSBuild\12.0\bin\;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\;C:\WINDOWS\SysWow64;;D:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\NativeBinaries/x86;D:\Libraries\bin\x64;D:\Libraries\bin\x32;D:\Libraries\bin;D:\Program Files (x86)\NVIDIA GPU Computing Toolkit\CUDA\v7.5\bin;D:\Program Files (x86)\NVIDIA GPU Computing Toolkit\CUDA\v7.5\libnvvp;D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin;D:\Python34;D:\Python34\Scripts;d:\Program Files (x86)\CMake\bin;D:\Perl64\site\bin;D:\Perl64\bin;d:\program files\ffmpeg\bin;D:\Program Files (x86)\CMake\bin;D:\Tools;D:\Python27;D:\Program Files (x86)\node-webkit;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files\Microsoft Windows Performance Toolkit;C:\Program Files\Microsoft\Web Platform Installer;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;D:\Program Files (x86)\Subversion\bin;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files (x86)\Git\cmd;C:\Program Files\TortoiseHg;d:\Program Files (x86)\NVIDIA Corporation\Cg\bin;d:\Program Files (x86)\NVIDIA Corporation\Cg\bin.x64;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\TortoiseGit\bin;C:\Program Files (x86)\Skype\Phone;D:\Program Files\nodejs;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Users\gygax\bin\Sencha\Cmd\5.1.2.52;D:\SourceLibs\Qt5\5.4\msvc2013_opengl\bin;d:\Ruby22-x64\bin;d:\SourceLibs\OpenSceneGraph-3.2.1\build\bin;D:\Libraries\OSG\bin;D:\Libraries\bin;D:\Projects\locsim\bin\v120;C:\users\gygax\commands;D:\Projects\Locsim\bin;D:\Tcl\bin;C:\Users\gygax\AppData\Roaming\npm

[Sibras]

That path is obviously for 2013 and I assume that 2015 isnt working either?

As for the double backslashes thats not a problem. Thats the same command line that everyone who uses the projects gets (and it works fine there).

The path you gave includes the Common7/tools directory that vsyasm should be in so it should be finding it without problem so its hard to tell what the error is. It shouldnt be an issue but you can remove the references to the "...VC/bin"vsyasm directory by editing the vsyasm.props file and changing the value of "YasmPath" from "$(VCInstallDir)bin" to "$(VSInstallDir)\Common7\Tools"

The last thing I can suggest is trying to get more detailed error messages from the yasm build task. Do this by setting the option "Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity" to detailed and then right clicking a single asm file in the project and selecting "compile".

[JPGygax68]

Thanks for your help Matt. I spent a lot of time on this, but I had to give up in the end. I went as far as creating a fake vsyasm.exe that would use _spawnv() to call the real one, making sure that it returned 0, not 1 as the exit code. I also enlisted procmon, which confirmed that vsyasm exits with status code 0.
Nothing going: MSBuild still says 'exited with code 1'.

At this point, there's nothing more I can do. If MSBuild is capable of making such mistakes, and without access to the source, I think it's beyond anyone's power to fix this.

I was considering asking the question at StackOverflow, but truth be told I'm feeling a bit too frustrated at this point to pour yet more work into this. What I'm doing is switching over to my laptop, which does not seem to have the problem. There is a different problem there - I may have to open a new issue regarding that one.

[cxsup]

You may reconsider building via msys2 (which includes yasm) as I mentioned here: #4 (comment)

I'm currently verifying the requirements on a clean Win10 workstation. I'll follow up.

[cxsup]

Successfully compiled a ReleaseDLLStaticDeps build using the repo code as of this post. The workstation is new with VS2013 SP5. As mentioned, I'm using msys2 (#4 (comment)) to do the heaving lifting prior to building ffmpeg.sln

It was necessary to drop in the vsyasm pieces:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations
   vsyasm.props
   vsyasm.targets
   vsyasm.xml

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
   vsyasm.exe

from www.tortall.net:
http://www.tortall.net/projects/yasm/releases/vsyasm-1.3.0-win32.zip (yes, win32)

I have to tweak the project_generate to get a working SLN for ReleaseDLLStaticDeps, but it works. Basically, I added $(OutDir)\bin\x64 as a lib search path, and moved the header/licence copy operation to the prelink stage.

C:\src\FFmpeg\shift\2015-10-21\msvc\bin\x64>ffmpeg
ffmpeg version 2.8.git Copyright (c) 2000-2015 the FFmpeg developers
  built with msvc
  configuration: --disable-gpl --disable-pthreads --disable-iconv --disable-sdl --enable-version3 --enable-avisynth --disable-nonfree 
         --disable-libmp3lame --disable-libvorbis --disable-libilbc --enable-libfdk-aac --disable-libtheora --disable-libsoxr --enable-librtmp 
         --disable-libmfx --disable-ffplay --disable-ffprobe --disable-ffserver --disable-postproc --toolchain=msvc
  libavutil      55.  4.100 / 55.  4.100
  libavcodec     57.  7.100 / 57.  7.100
  libavformat    57. 10.100 / 57. 10.100
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 12.100 /  6. 12.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

C:\src\FFmpeg\shift\2015-10-21\msvc\bin\x64>

To fetch and build the optional preliminaries, I'm using this script: #4 (comment) . The build sequence isn't quite right, so it's necessary to run through the build script a few times. And one of the projects is producing the msvc/bin as a file instead of directory. To correct this, delete the msvc/bin file, and instead create the directory, msvc/bin.

[Sibras]

Building via msys2 will not help as all your doing is calling msbuild from a shell (you can do this from within command prompt or powershell and it would be equivalent). MSYS2 includes yasm but it does it with a "yasm.exe", msbuild however will never use this as it is looking for the VS specific "vsyasm.exe". The problem is that msbuild has the internal vsyasm settings and it is responsible for resolving them, so if msbuild is failing it wont matter what shell you launch it from. So there are no advantages to using msys2 in this case, in fact I would recommend against it due to issues with clashing "link.exe" etc. I still use msys2 for many things as I think bash scripting is significantly better than stock windows alternatives, however for most users the recommended way to go would not involve msys2 as its quicker, easier and more reliable to just double click a project to open and then hit build.

Also the DLLStaticDeps projects link dll's using its dependencies static libraries (hence the name). Static libraries are output to $(OutDir)\lib\ so as not to clash with the shared libs output to the bin dir. By adding in $(OutDir)\bin\ your actually making the project link against shared libs and not the static ones. If you want to link against shared libs then the normal ReleaseDLL/DebugDLL projects are the ones setup to do that already. The only reason you may have issues with the DLLStaticDeps projects is if you havnt built the dependent static libraries before hand, the static configurations are Debug/Release which will create the required static libs when built.

[Sibras]

JPGygax68: Sorry to here its still not working, did you get any kind of additional information from msbuild by setting the output verbosity higher as that should have atleast given you something (normally that will spew out around 50+ lines when just compiling a single asm file)

[cxsup]

Understood. No more references to msys2. I elaborated on the vsyasm requirements with a link and layout in the subsequent post. Figured it was worth mentioning given I have a virgin environment to demonstrate what's required.

Regarding static dependencies, the compiled 3rd party libs live in ./lb. The compiled FFmpeg libs live in ./bin; thus, the necessary link path modification given the proj-gen templates only specify the ./lib directory.

BTW, the intermediary output collisions are noticeably gone. Thanks.

[Sibras]

You might want to check your projects. I just double checked the ones in the repo and static builds (Release/ReleaseLTO) are all output to /lib and shared builds (ReleaseDLL/ReleaseDLLStaticDeps) are all output to /bin as expected. So there shouldn't be any need to modify the projects.

And yes, hopefully the intermediary collisions are fixed as of a week or 2 ago as I try and fix these things as soon as they are raised (PS thanks for letting me know).

[JPGygax68]

Thanks to both of you, Sibras & cxsup. Like I said, I'll be happy to just use the libs my laptop is producing for now.
@Sibras: yes I did set the output level to verbose or even diag, but there was nothing helpful. The command line is correct, vsyasm executes correctly (did I mention that it does create the .obj file? also, procmon confirms that the exit code is 0), MSBuild spews out "exited with code 1".

[cxsup]

@Sibras I have no problem with the existing output. It's the library lib path that requires updating.

For the sake of sanity, I'll fork the project(s) and you can review if necessary. I can also work on the DOS batch script if that helps.

[Sibras]

OK well thats something that I dont think is easily rectifiable. If yasm is executing correctly but msbuild still decides to output an error code then clearly there is some serious internal error. Thats complete wipe and reinstall territory.

As for the library lib path would it be preferable if dynamic libs dont have the lib prefix and all are output to the lib dir instead of to the bin dir?

[JPGygax68]

Yes I agree, I'll have to consider a full reinstall of my system.. bummer.

Speaking of internal errors: compilation of libx265 aborts with an internal compiler error - on both my systems. I had to turn it off via the configurator.

Regarding the libs, the convention says that neither the DLL nor the import library should have the lib prefix. The DLLs still go to the bin/ directory and the import libs to the lib/ directory, where they will no longer overwrite the static libraries because those do have the lib prefix.

[Sibras]

Yep, im familiar with the standard naming conventions. The only reason these projects havnt used that previously is because they were ported from non-windows build chains. But given its a windows specific build I should probably move them over.

As for x265 thats an internal compiler bug that I had to work around that reared its head again with the 1.8 update when I enabled runtime selection of 8,10 or 12 bit encodes. It is fixed now in the repo.