flac dev - Jan 2016 - Lets do a 1.3.2 release

Janne Hyv?rinen wrote:
> Win_utf8 stuff should not be included in libflac since it's only to be
> used by the flac.exe frontend. It is not needed by other programs nor
> would they benefit from it without doing the extra work of converting
> their ansi filenames and functions to utf-8.
>
>> Version 2 of my patch attached, which fixes the problem for the
>> Makefile.lite and Visual Studio build systems without moving
>> win_utf8_io.c or touching the Autotools system.
>>
>> -Evan

When I compile flac project with MSYS/MinGW-w64, I can see two files:
libFLAC.a and libFLAC-static.a. The only difference between them
is that libFLAC.a contains functions from win_utf8_io.
But 'make install' adds libFLAC.a into /local/lib, not libFLAC-static.a.

lvqcl wrote:
>> Win_utf8 stuff should not be included in libflac since it's only to
be
>> used by the flac.exe frontend. It is not needed by other programs nor
>> would they benefit from it without doing the extra work of converting
>> their ansi filenames and functions to utf-8.
>>
>>> Version 2 of my patch attached, which fixes the problem for the
>>> Makefile.lite and Visual Studio build systems without moving
>>> win_utf8_io.c or touching the Autotools system.
>
> When I compile flac project with MSYS/MinGW-w64, I can see two files:
> libFLAC.a and libFLAC-static.a. The only difference between them
> is that libFLAC.a contains functions from win_utf8_io.
> But 'make install' adds libFLAC.a into /local/lib, not
libFLAC-static.a.

P.S.: Visual Studio creates libFLAC_static.lib and libFLAC_dynamic.dll, and
none of them contain win_utf8_io stuff.

lvqcl wrote:
>>> Win_utf8 stuff should not be included in libflac since it's
only to be
>>> used by the flac.exe frontend. It is not needed by other programs
nor
>>> would they benefit from it without doing the extra work of
converting
>>> their ansi filenames and functions to utf-8.
>>>
>>>> Version 2 of my patch attached, which fixes the problem for the
>>>> Makefile.lite and Visual Studio build systems without moving
>>>> win_utf8_io.c or touching the Autotools system.
>>
>> When I compile flac project with MSYS/MinGW-w64, I can see two files:
>> libFLAC.a and libFLAC-static.a. The only difference between them
>> is that libFLAC.a contains functions from win_utf8_io.
>> But 'make install' adds libFLAC.a into /local/lib, not
libFLAC-static.a.
>
>
> P.S.: Visual Studio creates libFLAC_static.lib and libFLAC_dynamic.dll, and
> none of them contain win_utf8_io stuff.
I was wrong.

In Visual Studio, 'flac' project depends on 'libFLAC_static'
project
and all the projects from src/share: getopt_static, grabbag_static,
replaygain_analysis_static, replaygain_synthesis_static,
utf8_static, win_utf8_io_static

Both 'libFLAC_static' and 'libFLAC_dynamic' projects depend
(only)
on 'win_utf8_io_static'.
I tried to remove this dependency and libFLAC_dynamic failed to compile
since metadata_iterators.c uses e.g. flac_fopen, which is defined in
share/compat.h as fopen_utf8.

   metadata_iterators.obj : error LNK2001: unresolved external symbol
unlink_utf8
   metadata_iterators.obj : error LNK2001: unresolved external symbol fopen_utf8
   metadata_iterators.obj : error LNK2001: unresolved external symbol utime_utf8
   metadata_iterators.obj : error LNK2001: unresolved external symbol
_stat64_utf8
   metadata_iterators.obj : error LNK2001: unresolved external symbol chmod_utf8
   metadata_iterators.obj : error LNK2001: unresolved external symbol
rename_utf8

So currently libFLAC on _WIN32 does depend on win_utf8_io.


BTW, share/compat.h includes share/win_utf8_io.h (if _WIN32 is defined),
and is included into many libFLAC source files. As a result, some libFLAC
source files unnecessarily include share/win_utf8_io.h, windows.h, etc.