similar to: [PATCH] fix dependencies for MSVC

Previously src/plugin_common library was used by flac own Winamp plugin (MSVC/Windows) and by XMMS plugin (*nix). The Winamp plugin is long gone from flac tree, so plugin_common is unused on Windows. This patch removes it from MSVC project files. -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_plugin_common_from_msvc.patch Type: application/octet-stream

As I wrote earlier, MSVC 2015 U2 incorrectly compiles stream_encoder_intrin_*.c files for x86-64 platform. As a result, flac works, but compression ratio is close to 1. This patch disables some compiler optimizations, and compression ratio reverts back to normal values. -------------- next part -------------- A non-text attachment was scrubbed... Name: msvc_bug.patch Type: application/octet-stream

Erik de Castro Lopo wrote: >> As I wrote earlier, MSVC 2015 U2 incorrectly compiles >> stream_encoder_intrin_*.c files for x86-64 platform. >> As a result, flac works, but compression ratio is close to 1. >> This patch disables some compiler optimizations, and >> compression ratio reverts back to normal values. > > Rather than having the same chunk of code in

Anybody still has MSVC 2015 update 1? It seems that MSVC 2015U2 miscompiles stream_encoder_intrin_sse2.c, stream_encoder_intrin_ssse3.c (and probably stream_encoder_intrin_avx2.c, but currently I cannot test it 'cause I don't have avx2 CPU). I wonder what happened and what changed in the asm code that MSVC generates.

There was a fix for a bug in MSVC 2015 update2: https://github.com/xiph/flac/commit/94a61241b02064c7d9fe508f72a742f2a90b8492 It seems that it's not the only version affected, see comment from 40th in this commit. Also, JRMC is affected: https://yabb.jriver.com/interact/index.php/topic,115742.0.html So, it makes sense to remove version check: better safe than sorry, and performance impact

1) Some time ago all project files for MSVC 6 were removed; it makes sense to remove the code that is necessary only for MSVC 6 and older compilers. --- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400 @@ -285,14 +285,7 @@ # ifdef USE_TRY_CATCH_FLAVOR _try { __asm { -# if _MSC_VER <= 1200 - /* VC6 assembler

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in

lvqcl wrote: > No, FLAC__AVX_SUPPORTED is 0 (initially it's undefined, then inside cpu.h > it's defined as 0). > > MSVC cannot discard unused references in debug builds and when LTCG is on, > for example: <http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html> > > And currently LTCG is enabled for release builds. Ok, I think I've fixed it

Here's a new version of a patch that fixes a problem with MSVC2105 update2, but it doesn't disable any optimization, so the resulting encoding performance should be almost unaffected by this workaround. MSVC compiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); into this: movq QWORD PTR [rsi], xmm2 while it should be movd

The set of four patches that remove dependency of libFLAC on win_utf8_io. Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite) Please review, especially makefile patches, I'm not very familiar with them. -------------- next part -------------- A non-text attachment was scrubbed... Name: 1_sources.zip Type: application/zip Size: 3524 bytes Desc: not available

These versions of Visual Studio don't have stdint.h and all [u]intNN_t types. But now these types are everywhere in FLAC codebase. An easy fix would be to move definitions of these types from share/compat.h into FLAC/ordinals.h (see attached patch). But it may break some 3rd party programs that include (directly or indirectly) this file and also have their own typedefs for these types.

For some reasons libFLAC_dynamic, libFLAC++_dynamic and libFLAC++_static projects depend on win_utf8_io_static project, but there's no such dependency for libFLAC_static project. The patch adds such dependency. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_dependency.patch Type: application/octet-stream Size: 1484 bytes Desc: not available Url :

Recently I downloaded MSVC++2005 Express Edition and it turns out that it wasn't possible to compile all files without several changes: 1) FLAC.sln has one extra "EndProject" line --- a\FLAC.sln 2013-06-17 11:57:09.000000000 +0400 +++ b\FLAC.sln 2013-08-16 20:19:34.630486700 +0400 @@ -157,7 +157,6 @@ EndProject Project("{4cefbc7c-c215-11db-8314-0800200c9a66}") =

Evan Ramos wrote: >> So currently libFLAC on _WIN32 does depend on win_utf8_io. > > Does my patch fix this issue on your end? BTW, your patch also changes MSVC solution/projects. What's the problem with them? I built flac/metaflac/libFLAC libraries with Visual Studio many times, and haven't noticed anything wrong.

lvqcl wrote: > 1) > Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with > VC2005 Express and doesn't allow to build 64-bit files/libraries. > > IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio > 2012/2013 Express are free and allow to build 64-bit files. > > VS 2005/2008 use .vcproj files, and VS

On 09-03-13 01:01, Erik de Castro Lopo wrote: > I would like to know how many years I have to wait before we can ditch > this stuff. I intend to do some testing on platforms I have available > today and roll a second pre-release after my testing. Talking about ditching, there are still .dsp files in the repository, these are MSVC 6 files. I haven't seen anyone on the list testing

lvqcl wrote: > Also MSVC fails because src/libFLAC/include/private/bitmath.h now > contains "uint32_t long idx" instead of "unsigned long idx". Ah, missed that because it was MSVC code. They should be `uint64_t`. > According to MSDN _BitScanReverse*() functions have signatures: > unsigned char _BitScanReverse(unsigned long *, unsigned long); > unsigned char

lvqcl wrote: > > These versions of Visual Studio don't have stdint.h and > > all [u]intNN_t types. But now these types are everywhere > > in FLAC codebase. > > Here is the patch that fixes the problem: > it moves definitions of all [u]intNN_t types from share/compat.h > into new file share/msvc2005_int.h and then includes this file > into all files (via

First off, this code is horrible to read and work on. The recent commits are the first of what I hope is a massive clean up of this code. lvqcl wrote: > So if I understand things correctly, the current meaning of --(en|dis)able-sse is: > > on Linux: > --enable-sse: > add -msse2 to the compiler switches > do not test SSE OS support (assume that SSE is

Erik de Castro Lopo wrote: > Ok, I'll take the original patch as it is. DO you have a link to a > bug report on this problem? It would be nice to put it in a comment > above the workaround. :sigh: I hoped that somebody else will find what's wrong and will create a bugreport... Well, here is the link: