Compile with libraries with MSVC

[dimasafonis]

I can't compile libraries using MSVC 2022.
This line:
./configure --toolchain=msvc
creates libraries in .a format which is incompatible with MSVC.
This line:
./configure --toolchain=msvc --enable-shared
creates normal .lib and .dll files, but I can't use it with pkg-config because pkg-config uses -lm flag but there's no m.lib file in Windows.

[Balling]

Last time msvc worked was in 2021. ​https://github.com/mcmtroffaes/ffmpeg-msvc-build

There were some fixes since then but I dunno whether it works.

​https://github.com/FFmpeg/FFmpeg/search?o=desc&q=msvc&s=committer-date&type=commits

And anyway, MSVC produces worse binaries than gcc for windows.

[Balling]

creates libraries in .a format which is incompatible with MSVC.

Why? .a file is just a static linked library, called .lib in windows. .dll is on linux .so and is dynamic (well, except for the whole ld-linux.so mess, cause ld-linux.so is an executable really, link to ld-linux.so is absolute in all .so).

Does renaming to .lib work?

[dimasafonis]

Renaming to .lib works. Thank you very much.
I thought it's an ar archive and msvc can't work with it.
Now it works, but why does configure set a static library prefix incorrectly?
And why does it search for the m library on windows? It checks if dlopen and dlsym are in a separate library or not. So why doesn't it do the same with m library?

[Balling]

but why does configure set a static library prefix incorrectly?

Does it even support VS 2022?

and why does it search for the m library on windows

You mean libm.so? You do understand windows math.h standard library is also called libm, right? ​https://github.com/amd/win-libm/blob/master/pow.asm#L108

[ArseGnomes]

Replying to Balling:

And anyway, MSVC produces worse binaries than gcc for windows.

I'm not going to disagree fully because I don't have the data, but based on experience, I kinda doubt it... on the condition that ffmpeg doesn't use any of the emulation APIs (pthreads, etc) that most GPL stuff tends towards. I'm sure those build worse on MSVC since they're not meant for it in the first place. There should really be a movement to start eliminating all of that stuff and conditionally using Windows APIs regardless of how painful it'll be (even switching to something like cmake to eliminate the need for autotools; possibly the only thing more archaic than cmake; would be a great jump forward), but it's not worth bringing up windows anywhere near a GPL codebase, usually. FFMPEG is better than most projects about it, some don't care, others you'll get a slew of "just switch to linux id10T" style responses.

If I ever get bored enough to get it working I'll know for sure, but I highly doubt I'll have the time. Here's my bit of data though:

While initially testing to see what I could do about getting x265 encoding speeds higher on my old workstation, besides the huge boost from killing off the spectre / meltdown mitigations in the registry, I needed to do encodes on files with HDR metadata / Dolby Vision prior to ffmpeg supporting one or the other of those.

While testing 10-bit x265 encoding, I found that piping y4m frames from ffmpeg to an external MSVC-built x265 was ~20% faster than using the internal static linked x265. I tracked down a newer PGO build of x265 that put it more in the 20-30% range depending on options and resolution. x265 is something like 70% assembly language so something else ugly is going on. I suspect either thread-related or memory management related because piping that much data to another process shouldn't be faster than statically linked code. That's the only data I have on it really, maybe it's just libx265, who knows.

[Balling]

but based on experience, I kinda doubt it

Any code I ever tried or saw comparison on the Interent was faster for gcc than msvc. MSVC is Microsoft project. They cannot compete with clang and gcc, that is why they now give clang with Visual Studio 2022 and compile kernel with clang.

As for x265, report that to x265 repo. Anyway, PGO can really change the speed, for example clang itself is faster: ​https://www.phoronix.com/news/LLVM-PGO-Windows-Build

And they did not even enable ThinLTO.

[Balling]

And BTW, here is a good link on it I just found. MSVC is really not quite there. Though Wolfram Mathematica (you need last 13.3.1 version) does use it with CUDA...

​https://www.reddit.com/r/cpp/comments/100vctp/msvc_vs_clang_performance_has_anyone_tested/

It is also quite strange Nvidia uses it to compile the driver. Cannot wait when they enable GSP-RM on Windows 11.