ShiftMediaProject / FFVS-Project-Generator

A program that can scan existing FFmpeg/LibAV source files and dynamically generate a Visual Studio project file.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Winsock errors when building ffmpeg.exe

Dan203 opened this issue · comments

Do you know why I get a bunch of errors about redefinition of types/functions in winsock2.h when trying to build ffmpeg.exe?

Ill need a bit more information than that. Although generally these errors are due to windows.h being included in a source file before winsock2.h. This is due to windows.h by default including winsock.h (note the lack of '2') which will conflict with winsock2.h.

So if you've modified the code in anyway then make sure that winsock2.h is included before windows.h or any other header that may include windows.h.

I haven't modified the source. I downloaded the official repo and switched to the release/3.3 branch. I put your app in a folder inside the ffmpeg source folder called SMP and ran it with no options. (all default)

I noticed you have the two exe files unchecked in all the build configs, so I assumed this was some sort of known issue. I haven't tried your repo. Do you have any fixes in your repo for this?

Oh if it matters I'm building the DLL version with static dependencies.

The only reason the exe's are disabled in most configs is because of the build bot i use to create weekly releases. Since there is no point compiling each exe multiple different ways (shared/static etc.) by default just the static release build is enabled by default. But all other builds work fine and are tested regularly.

As for my ffmpeg repo it is an exact clone of ffmpeg master just with the pre-generated VS projects included. So no special fixes are required.

I just tested on mine and everything builds fine with the master branch. Perhaps try building from master and see if that fixes the problem. If not send me the command line used to generate the project as there may actually be a bug in the ffmpeg source code itself.

The command line I use is minimal. Most of it I don't even think applies with your tool. (I used mingw before this) I'm not at my desk right now, but I'll look it up on Monday when I'm back at work and post it. I'm pretty sure it's something like...

--disable-docs --enable-shared --disable-devices --enable-zlib --tool-chain=msvc

I only recently started using zlib in the build because I ran into a file that had a compressed header and wouldn't open without it. My main goal is to create a minimal lgpl build with most of the encoders, decoders and muxers. We really only use the DLLs in our product, but the exe is nice to have for testing so we can tell if our code is an issue or if it's ffmpeg.

FYI I work on a relatively popular video editing app called VideoReDo, in case you're wondering. We use ffmpeg for a few things in the current version but we're planning on using it more in our next major release. That's why I'm finally putting in the time to get this working in VS, because debugging in mingw/gcc is a pain in the ass.

Here is the exact one I used...

--disable-doc --enable-shared --disable-ffplay --disable-ffserver --enable-zlib --toolchain=msvc

Ive tried the command line you used and i can not reproduce any issues using the current version of ffmpeg master. This is not surprising as FFVS actually does a msvc compile pass over the source files during the DCE and definitions generation stages. So if there was an error in the code then it will show up during FFVS generation first.

So for you to get compile errors something must be different from when FFVS does its test compilation and when you go and build the project yourself. So its hard for me to to help as i cant replicate it. If you can tell me which specific source file generates the errors when compiled then I may be able to look at it further.

Are you still getting errors with the latest FFVS and ffmpeg. If not let me know so can close this ticket.

Sorry I had been working on another project. I just tried again and I'm still getting this error. I even tried upgrading to VS2017 and Windows SDK 10. (was using VS2015 and Windows SDK 8.1 before)

I get a bunch of errors like this...

1>c:\users\dan\documents\videoredo source\ffmpeg\smp../compat/atomics/win32/stdatomic.h(107): warning C4022: '_InlineInterlockedCompareExchangePointer': pointer mismatch for actual parameter 1
1>c:\users\dan\documents\videoredo source\ffmpeg\smp../compat/atomics/win32/stdatomic.h(107): warning C4022: '_InlineInterlockedCompareExchangePointer': pointer mismatch for actual parameter 2
1>c:\users\dan\documents\videoredo source\ffmpeg\smp../compat/atomics/win32/stdatomic.h(107): warning C4022: '_InlineInterlockedCompareExchangePointer': pointer mismatch for actual parameter 3
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\shared\ws2def.h(235): error C2011: 'sockaddr': 'struct' type redefinition
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\winsock.h(482): note: see declaration of 'sockaddr'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\shared\ws2def.h(437): error C2059: syntax error: 'constant'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\shared\ws2def.h(633): error C2011: 'sockaddr_in': 'struct' type redefinition
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\winsock.h(309): note: see declaration of 'sockaddr_in'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\winsock2.h(136): error C2011: 'fd_set': 'struct' type redefinition
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\um\winsock.h(65): note: see declaration of 'fd_set'
.......

Which version of the Windows SDK are you using?

Currently I use the latest windows 10 sdk but that wont effect it as the CI I use builds for various SDK versions and with VS 2013, 2015 and 2017 and all versions test fine (you can see the created static+shared(with static deps) libs on the releases page).

Based on the warnings you listed above it would appear that you are using an older version of ffmpeg source as these issues have been corrected in newer ffmpeg master. FFVS just allows for building directly with VS so if there is an error in the underlying ffmpeg source then that has to be corrected in the ffmpeg source itself.

Ive previously tested your command using master branch and it worked fine so it must be an issue in the source code for the release you are using. I suggest you upgrade your ffmpeg source to master or if you dont want to do that then a work around would be to just modify your VS project by going to "Project Properties-> C/C++-> Advanced" and force include the winsock2.h file.

My boss will only allow me to use official releases. I tried 3.3.4 and I get the same error. I can build the code in GCC using mysys and it works, so this is something specific to the VS build.

Not a big deal. If you don't know what's causing it then I'll either figure it out myself or just forget about it. We really only use the libs in our product anyway. I only ever use the ffmpeg.exe for testing to see if something that's not working is my code or ffmpeg.

OK I got it working. I just copied the "compat" directory from the current development tree and now it builds. There must have been some sort of error in there.

Thanks again for this great project! Maintaining and debugging ffmpeg compiled in mysys/GCC was a huge pain. This has made my life so much easier.

Now you mention it I vaguely remember a ffmpeg bug in one of the compat headers that caused the kind of issues your having which was fixed some time ago. However i don't remember enough to know what the fix is.

Unfortunately the way ffmpeg works is that all development is done on the master branch and so that is the one that actually gets tested. Any bug fixes are applied to master and only back ported to release branches if someone actually remembers to do so (and due to the changing state of master those fixes may not directly apply to the older branches anyway). So most ffmpeg devs just work directly off master (as master is considered always stable) so the release branches dont get much internal attention.

Anyway glad to hear its all fixed now.