Re: [flac-dev] Lets do a 1.3.2 release

2016-01-30 Thread lvqcl 
lvqcl wrote:

> Erik de Castro Lopo wrote:
>> Ok, lets do it.
>
> I just thought that it's more complicated. All *file* functions should
> really be moved to libFLAC. But other functions should not, because
> libFLAC doesn't use them.
>

I'm thinking about writing my own patch to fix libFLAC -- win_utf8_io
dependency. It'll keep win_utf8_io library and move only necessary
functions into libFLAC. It's more elegant and simple (I hope).
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-30 Thread Erik de Castro Lopo 
lvqcl wrote:

> I'm thinking about writing my own patch to fix libFLAC -- win_utf8_io
> dependency. It'll keep win_utf8_io library and move only necessary
> functions into libFLAC. It's more elegant and simple (I hope).

Sounds reasonable. Thanks.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-28 Thread Erik de Castro Lopo 
lvqcl wrote:

> Currently functions in win_utf8_io.c are a compatibility layer for
> libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC.

Ok, lets do it.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-24 Thread Erik de Castro Lopo 
Dave Yeo wrote:

> After this the build dies with,
> util.c: In function 'benchmark_function':
> util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use 
> in this function)
>clock_gettime (CLOCK_PROCESS_CPUTIME_ID, ) ;
> 
> Would using gettimeofday() be accurate enough?

AS a fall back yes, but not as replacement on platforms with clock_gettime().

> Perhaps simpler just to 
> disable the microbench test on OS/2 as gettimeofday() would require a 
> configure test and OS/2 is a minor platform?


I would accept a patch that disables the microsbenchmark on OS/2 I would
also accept one that uses gettimeofday() when clock_gettime() is not
available.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-22 Thread lvqcl 
lvqcl wrote:

> Evan Ramos wrote:
>
>> 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.


As far as I understand the problem: if some program wants to use
libFLAC.lib, it also has to be linked with win_utf8_io, which is
a bit surprising because a program doesnt really need this library,
and this requirement isn't documented anywhere... And since win_utf8_io
is basically a 'compatibility' layer between libFLAC and Windows,
it makes sense to include win_utf8_io into libFLAC. Do I understand
it right?

Then IMHO all three build systems (configure && make, Makefile.lite
and MSVC) should be synchronized with each other, and your first patch
seems better.



*
TO ERIK:

I have some patches, but they either modify MSVC .vcxproj files,
or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos.
So should they be applied? rejected? postponed until after flac 1.3.2?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-22 Thread Erik de Castro Lopo 
lvqcl wrote:

> Then IMHO all three build systems (configure && make, Makefile.lite
> and MSVC) should be synchronized with each other

+1


> TO ERIK:
> 
> I have some patches, but they either modify MSVC .vcxproj files,
> or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos.
> So should they be applied? rejected? postponed until after flac 1.3.2?

We should figure out the bext way to get them appled.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-19 Thread lvqcl 
Dave Yeo wrote:

>> I cannot find information what version of binutils supports AVX/AVX2/FMA
>> instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
>> so it doesn't matter much.
>
> Surprisingly, I've yet to have a report of an AVX related crash or trap
> (used in FFmpeg and projects based on it, Mozilla, probably others).
> As I understand it, support is a matter of saving the extended registers
> during a context switch and perhaps our kernel had some future proofing
> added towards the end.

WinXP/Vista also don't support AVX but ffmpeg doesn't crash there.

IIRC, OS must explicitely enable AVX support, and an application must check
whether the OS supports AVX or not.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-19 Thread Dave Yeo 
On 01/19/16 01:04 PM, lvqcl wrote:
> Dave Yeo wrote:
>
>>> I cannot find information what version of binutils supports AVX/AVX2/FMA
>>> instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
>>> so it doesn't matter much.
>>
>> Surprisingly, I've yet to have a report of an AVX related crash or trap
>> (used in FFmpeg and projects based on it, Mozilla, probably others).
>> As I understand it, support is a matter of saving the extended registers
>> during a context switch and perhaps our kernel had some future proofing
>> added towards the end.
>
> WinXP/Vista also don't support AVX but ffmpeg doesn't crash there.
>
> IIRC, OS must explicitely enable AVX support, and an application must check
> whether the OS supports AVX or not.

OK, that makes sense and after looking quickly at Agners 
optimizing_assembly.pdf I can see how FFmpeg does it though I still find 
it hard to follow the code in flac.
The second version of the patch is to be preferred.
I'll have to ask the Russians about their alternative kernel (OS/4)
Dave
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-18 Thread lvqcl 
Dave Yeo wrote:

> Seems that the default binutils on OS/2 is too old to support AVX2,
> attached patch works around this. Not the best solution as best would be
> configure tests, but simple.

Are you sure that these binutils support AVX and FMA? (Currently libFLAC
doesn't contain AVX and FMA instructions). If they aren't supported then
it's better to include them too into #if !defined __OS2__ ... #endif.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-18 Thread Dave Yeo 
On 01/18/16 01:46 PM, lvqcl wrote:
> Dave Yeo wrote:
>
>> The nature of the error implies AVX2 support that is missing but I'm not
>> much up on assembly,
>>
>> Best to be safe so updated patch attached.
>> I've also opened a ticket, http://trac.netlabs.org/rpm/ticket/165#ticket
>> Dave
>
> I cannot find information what version of binutils supports AVX/AVX2/FMA
> instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
> so it doesn't matter much.

Surprisingly, I've yet to have a report of an AVX related crash or trap 
(used in FFmpeg and projects based on it, Mozilla, probably others).
As I understand it, support is a matter of saving the extended registers 
during a context switch and perhaps our kernel had some future proofing 
added towards the end.
Dave
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-18 Thread lvqcl 
Dave Yeo wrote:

> The nature of the error implies AVX2 support that is missing but I'm not
> much up on assembly,
>
> Best to be safe so updated patch attached.
> I've also opened a ticket, http://trac.netlabs.org/rpm/ticket/165#ticket
> Dave

I cannot find information what version of binutils supports AVX/AVX2/FMA
instructions, but IIRC OS/2 doesn't support AVX instructions anyway,
so it doesn't matter much.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-18 Thread Dave Yeo 

On 01/18/16 07:42 AM, lvqcl wrote:

Dave Yeo wrote:


>Seems that the default binutils on OS/2 is too old to support AVX2,
>attached patch works around this. Not the best solution as best would be
>configure tests, but simple.

Are you sure that these binutils support AVX and FMA? (Currently libFLAC
doesn't contain AVX and FMA instructions). If they aren't supported then
it's better to include them too into #if !defined __OS2__ ... #endif.


The nature of the error implies AVX2 support that is missing but I'm not 
much up on assembly,

make[4]: Entering directory `K:/usr/local/src/flac/src/libFLAC'
  CC   lpc_intrin_avx2.lo
R:/tmp/ccwvrScM.s: Assembler messages:
R:/tmp/ccwvrScM.s:495: Error: operand type mismatch for `vbroadcastss'
...
R:/tmp/ccwvrScM.s:8773: Error: operand type mismatch for `vpsrlq'
R:/tmp/ccwvrScM.s:8778: Error: no such instruction: `vpermd 
%ymm1,%ymm5,%ymm0'

R:/tmp/ccwvrScM.s:8859: Error: operand type mismatch for `vpmovzxdq'
...

Best to be safe so updated patch attached.
I've also opened a ticket, http://trac.netlabs.org/rpm/ticket/165#ticket
Dave
From dc164a696709fc9965a1c8c452800c596872d993 Mon Sep 17 00:00:00 2001
From: Dave Yeo 
Date: Mon, 18 Jan 2016 10:31:51 -0800
Subject: [PATCH] OS/2 currently has too old of a binutils to support AVX

Signed-off-by: Dave Yeo 
---
 src/libFLAC/include/private/cpu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/libFLAC/include/private/cpu.h b/src/libFLAC/include/private/cpu.h
index 380f4f0..1c8428c 100644
--- a/src/libFLAC/include/private/cpu.h
+++ b/src/libFLAC/include/private/cpu.h
@@ -78,9 +78,11 @@
 #define FLAC__SSE2_SUPPORTED 1
 #define FLAC__SSSE3_SUPPORTED 1
 #define FLAC__SSE4_1_SUPPORTED 1
+#if !defined __OS2__
 #define FLAC__AVX_SUPPORTED 1
 #define FLAC__AVX2_SUPPORTED 1
 #define FLAC__FMA_SUPPORTED 1
+#endif
   #else /* for GCC older than 4.9 */
 #define FLAC__SSE_TARGET(x)
 #ifdef __SSE__
-- 
2.0.0

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-16 Thread lvqcl 
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.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread Thomas Zander 
On 8 January 2016 at 11:56, Erik de Castro Lopo  wrote:

> I think its time for a new release. The current code base is stable
> and I've been building it for x86_64/linux, powerpc/linux, armhf/linux,
> x86_64/darwin in a Jenkins build bot.

Yes, great idea! This is an active project with active development, we
should release every now and then :-)

>   * Upload Windows Zip to sourceforge.net.

Regarding sourceforge ... sorry in case this has been debated and
discussed before, but the dominant social coding platform these days
is github. New potential contributors are much more likely to already
have a GitHub account than SF and contribution via GH is working
really well already. My suggestion is to move issue tracking to GH and
make it clear on the SF project page that issues should be filed on GH
and development/contributions via GH is preferred. Also the wiki on SF
should be dropped since it is not used at all.

Best regards
Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread lvqcl 
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.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread lvqcl 
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.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread Evan Ramos 
lvqcl wrote:

> 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.

Thank you for checking this. I've always had trouble with Autotools on
Windows, even when running them from a non-Windows machine first.

> So currently libFLAC on _WIN32 does depend on win_utf8_io.

Does my patch fix this issue on your end?

> 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.

It looks like win_utf8_io.h only includes windows.h in order to have
the proper types to declare CreateFile_utf8, which is used in
src/flac/decode.c and src/share/grabbag/file.c. I suppose those two
files could #define FLAC__INCLUDE_WINAPI and win_utf8_io.h could guard
the include and CreateFile_utf8 declaration with it, if we wanted to
avoid windows.h. If we wanted to avoid share/win_utf8_io.h completely,
we would need to do something similar in the 34 files that use
flac_(printf|fprintf|vfprintf|fopen|chmod|utime|stat|unlink|rename),
which would be counterproductive to the purpose of compat.h.

On the topic of header minimalism, we may want to #define
WIN32_LEAN_AND_MEAN and NOGDI before every #include  in the
codebase.


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.

libFLAC.a(metadata_iterators.release.o): In function
`simple_iterator_prime_input_':
flac/src/libFLAC/metadata_iterators.c:427: undefined reference to `fopen_utf8'
flac/src/libFLAC/metadata_iterators.c:424: undefined reference to `fopen_utf8'
libFLAC.a(metadata_iterators.release.o): In function `set_file_stats_':
flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8'
flac/src/libFLAC/metadata_iterators.c:3356: undefined reference to `utime_utf8'
flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8'
flac/src/libFLAC/metadata_iterators.c:3356: undefined reference to `utime_utf8'
flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8'
flac/src/libFLAC/metadata_iterators.c:3356: undefined reference to `utime_utf8'
libFLAC.a(metadata_iterators.release.o): In function
`simple_iterator_prime_input_':
flac/src/libFLAC/metadata_iterators.c:427: undefined reference to `fopen_utf8'
libFLAC.a(metadata_iterators.release.o): In function `get_file_stats_':
flac/src/libFLAC/metadata_iterators.c:3343: undefined reference to
`_stat64_utf8'
libFLAC.a(metadata_iterators.release.o): In function `set_file_stats_':
flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8'
flac/src/libFLAC/metadata_iterators.c:3356: undefined reference to `utime_utf8'
libFLAC.a(metadata_iterators.release.o): In function
`simple_iterator_prime_input_':
flac/src/libFLAC/metadata_iterators.c:424: undefined reference to `fopen_utf8'
libFLAC.a(metadata_iterators.release.o): In function `open_tempfile_':
flac/src/libFLAC/metadata_iterators.c:3284: undefined reference to `fopen_utf8'
libFLAC.a(metadata_iterators.release.o): In function `cleanup_tempfile_':
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
libFLAC.a(metadata_iterators.release.o):flac/src/libFLAC/metadata_iterators.c:3306:
more undefined references to `unlink_utf8' follow
libFLAC.a(metadata_iterators.release.o): In function `transport_tempfile_':
flac/src/libFLAC/metadata_iterators.c:3314: undefined reference to `rename_utf8'
libFLAC.a(metadata_iterators.release.o): In function `cleanup_tempfile_':
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
libFLAC.a(metadata_iterators.release.o): In function `set_file_stats_':
flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8'
flac/src/libFLAC/metadata_iterators.c:3356: undefined reference to `utime_utf8'
libFLAC.a(metadata_iterators.release.o): In function `cleanup_tempfile_':
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
flac/src/libFLAC/metadata_iterators.c:: undefined reference to `unlink_utf8'
libFLAC.a(metadata_iterators.release.o): In function `chain_read_':

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread Dave Yeo 

On 01/08/16 02:56 AM, Erik de Castro Lopo wrote:

HI all,

I think its time for a new release. The current code base is stable
and I've been building it for x86_64/linux, powerpc/linux, armhf/linux,
x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been
building regularly on their platforms of interest


Seems that the default binutils on OS/2 is too old to support AVX2, 
attached patch works around this. Not the best solution as best would be 
configure tests, but simple.
I'll file a bug about this but it'll be a while before anything is done 
about it.

After this the build dies with,
util.c: In function 'benchmark_function':
util.c:124:17: error: 'CLOCK_PROCESS_CPUTIME_ID' undeclared (first use 
in this function)

  clock_gettime (CLOCK_PROCESS_CPUTIME_ID, ) ;

Would using gettimeofday() be accurate enough? Perhaps simpler just to 
disable the microbench test on OS/2 as gettimeofday() would require a 
configure test and OS/2 is a minor platform?

Dave
From 15985f472037734032183a399b5841a09a0dc950 Mon Sep 17 00:00:00 2001
From: Dave Yeo 
Date: Sat, 9 Jan 2016 22:34:44 -0800
Subject: [PATCH] OS/2 currently has too old of a binutils to support AVX2

Signed-off-by: Dave Yeo 
---
 src/libFLAC/include/private/cpu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/libFLAC/include/private/cpu.h b/src/libFLAC/include/private/cpu.h
index 380f4f0..1e737cb 100644
--- a/src/libFLAC/include/private/cpu.h
+++ b/src/libFLAC/include/private/cpu.h
@@ -79,7 +79,9 @@
 #define FLAC__SSSE3_SUPPORTED 1
 #define FLAC__SSE4_1_SUPPORTED 1
 #define FLAC__AVX_SUPPORTED 1
+#if !defined __OS2__ /* Currently binutils are too old to support AVX2 */
 #define FLAC__AVX2_SUPPORTED 1
+#endif
 #define FLAC__FMA_SUPPORTED 1
   #else /* for GCC older than 4.9 */
 #define FLAC__SSE_TARGET(x)
-- 
2.0.0

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread Janne Hyvärinen 
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.


--
Janne

On 9.1.2016 5.08, Evan Ramos wrote:

lvqcl wrote:


IIRC libFLAC.a built with "./autogen.sh && ./configure && make"
contains all functions from win_utf8_io. So I think it's possible
to change some Makefile.lite or maybe build/*.mk files so that
there will be no need to add -lwin_utf8_io to -lFLAC.

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


___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Erik de Castro Lopo 
Evan Ramos wrote:

>  If so, I can provide a patch that does this.

Yes please.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Evan Ramos 
Erik de Castro Lopo wrote:

>> Patch attached.
>
> Sorry, I misunderstood your intention. The utf8_static library should
> stay as a separate component, but should be statically linked as needed
> (ie its only needed for Windows)

My patch does not touch src/share/utf8, only src/share/win_utf8_io,
which the objects in libFLAC.a depend on. Without the patch, any
Windows project that links with -lFLAC would need to modify their
build scripts to add -lwin_utf8_io (as opposed to the library being
self-sufficient, other than libogg, optionally).

-Evan
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Erik de Castro Lopo 
Evan Ramos wrote:

> Erik de Castro Lopo wrote:
> 
> >> Patch attached.
> >
> > Sorry, I misunderstood your intention. The utf8_static library should
> > stay as a separate component, but should be statically linked as needed
> > (ie its only needed for Windows)
> 
> My patch does not touch src/share/utf8, only src/share/win_utf8_io,
> which the objects in libFLAC.a depend on. Without the patch, any
> Windows project that links with -lFLAC would need to modify their
> build scripts to add -lwin_utf8_io (as opposed to the library being
> self-sufficient, other than libogg, optionally).

I may have double misunderstood :-). Let me have another look.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread lvqcl 
Evan Ramos wrote:

>> Sorry, I misunderstood your intention. The utf8_static library should
>> stay as a separate component, but should be statically linked as needed
>> (ie its only needed for Windows)
>
> My patch does not touch src/share/utf8, only src/share/win_utf8_io,
> which the objects in libFLAC.a depend on. Without the patch, any
> Windows project that links with -lFLAC would need to modify their
> build scripts to add -lwin_utf8_io (as opposed to the library being
> self-sufficient, other than libogg, optionally).

IIRC libFLAC.a built with "./autogen.sh && ./configure && make"
contains all functions from win_utf8_io. So I think it's possible
to change some Makefile.lite or maybe build/*.mk files so that
there will be no need to add -lwin_utf8_io to -lFLAC.

Unfortunately I don't know much about this build system, and I can't
help here.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Evan Ramos 
> Yes please.

Patch attached.

-Evan


merge win_utf8_io into libFLAC.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Erik de Castro Lopo 
HI all,

I think its time for a new release. The current code base is stable
and I've been building it for x86_64/linux, powerpc/linux, armhf/linux,
x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been
building regularly on their platforms of interest.

I made a first pass on an update to the changelog.html. I' also putting
toether a release checklist that I will add to the git repo at some 
stage. Fo far that checklst contains:

  * Update release notes.
  * Make sure all files have current release year on copyright notice.
  * Git tag the release commit.
  * Upload the source tarball and flac-x.y.x-win.zip (32 and 64 bit) to:

https://svn.xiph.org/releases/flac/

  * Upload Windows Zip to sourceforge.net.

I'm currently reading through the emails from the 1.3.1 release to see
what else needs to be done.

So, please test and remind me of anything I may have forgotten.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Erik de Castro Lopo 
Evan Ramos wrote:

> > Yes please.
> 
> Patch attached.

Sorry, I misunderstood your intention. The utf8_static library should
stay as a separate component, but should be statically linked as needed
(ie its only needed for Windows)

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Evan Ramos 
lvqcl wrote:

> IIRC libFLAC.a built with "./autogen.sh && ./configure && make"
> contains all functions from win_utf8_io. So I think it's possible
> to change some Makefile.lite or maybe build/*.mk files so that
> there will be no need to add -lwin_utf8_io to -lFLAC.

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


win_utf8_io library fix.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread MauritsVB 
Great stuff!

For the checklist, can I suggest you also make sure all resulting FLAC files 
are encoded with the new date in their encoder string? 

As for the changelog, I have kept track of those changes that might be more 
interesting for end-users and developers using the format (so no build-system 
improvements for instance). Now, I’d be the first to admit that I haven’t 
always been paying attention so you are probably better positioned to decide 
what I’ve missed and what shouldn’t make the cut. These were on my list that I 
believe you haven’t covered yet:


Changed the LPC order guess for a slight compression improvement, particularly 
for classical music
http://git.xiph.org/?p=flac.git;a=commit;h=c97e057ee57d552a3ccad2d12e29b5969d04be97

Improved encoding speed on older Intel CPUs
https://git.xiph.org/?p=flac.git;a=commitdiff;h=ac0b4b4cab42fdd5c010bac85bf4e63f49647e69

libFLAC: Support 64bit brword/bwword allowing FLAC__BYTES_PER_WORD to be set to 
8. This is disabled by
default.

libFLAC: Fix potential memory leaks
https://git.xiph.org/?p=flac.git;a=commit;h=15a9062609c123b56df104a575dba657c2577e0b

Fixed a segmentation fault in libFLAC
http://sourceforge.net/p/flac/bugs/425/

Put an upper bound on the number of seek points
https://git.xiph.org/?p=flac.git;a=commitdiff;h=033af7bf1cd035772a199d07342038619c019993


Thanks,
Maurits


> On 8 Jan 2016, at 10:56, Erik de Castro Lopo  wrote:
> 
> HI all,
> 
> I think its time for a new release. The current code base is stable
> and I've been building it for x86_64/linux, powerpc/linux, armhf/linux,
> x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been
> building regularly on their platforms of interest.
> 
> I made a first pass on an update to the changelog.html. I' also putting
> toether a release checklist that I will add to the git repo at some 
> stage. Fo far that checklst contains:
> 
>  * Update release notes.
>  * Make sure all files have current release year on copyright notice.
>  * Git tag the release commit.
>  * Upload the source tarball and flac-x.y.x-win.zip (32 and 64 bit) to:
> 
>   https://svn.xiph.org/releases/flac/
> 
>  * Upload Windows Zip to sourceforge.net.
> 
> I'm currently reading through the emails from the 1.3.1 release to see
> what else needs to be done.
> 
> So, please test and remind me of anything I may have forgotten.
> 
> Cheers,
> Erik
> -- 
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread lvqcl 
Erik de Castro Lopo wrote:

> I'm currently reading through the emails from the 1.3.1 release to see
> what else needs to be done.
>
> So, please test and remind me of anything I may have forgotten.

Looking at the bug list at SF:  -

"libFLAC and flac need checks where padding is specified or merged
to make sure the size does not exceed the metadata block size limit
of 2^24 bytes".

And indeed the command like "flac.exe -P 5000 test.wav" produces
corrupted FLAC stream.

Also flac.exe hangs if I try to embed very big (~30Mb) picture.

I'll try to find the bugs and fix the issues.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-08 Thread Evan Ramos 
Currently, using the Makefile.lite build system with MinGW-w64 will
produce a libFLAC.a that depends on libwin_utf8_io.a. Without it, a
project building with just libFLAC.a will generate undefined reference
errors at link time.

metadata_iterators.c: fopen_utf8, chmod_utf8, utime_utf8,
_stat64_utf8, unlink_utf8, rename_utf8
stream_decoder.c: fopen_utf8

I don't think libFLAC.a should depend on another library built
alongside it, much less one with only one object. Given that all other
targets in the build system depend on libFLAC anyway, would it make
sense to move win_utf8_io.c from src/share/win_utf8_io/ to
src/libFLAC/? If so, I can provide a patch that does this.

Best,
Evan
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev