Hi all,
It sees that the most serious bug in the flac bug tracker:
https://sourceforge.net/p/flac/bugs/413/
has been fixed in git. This fix alone is worth a new release so its
time to work towards one.
Things I need to do for this new release:
* Deal with all current patches on the mailing list.
* Review all bugs reported against 1.3.0 on the sf.net.
* Testing and coordination of testing across platforms and build systems.
Anything else I've forgotten or people would like to see?
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Erik de Castro Lopo wrote:> It sees that the most serious bug in the flac bug tracker: > > https://sourceforge.net/p/flac/bugs/413/ > > has been fixed in git. This fix alone is worth a new release so its > time to work towards one. > > Things I need to do for this new release: > > * Deal with all current patches on the mailing list. > * Review all bugs reported against 1.3.0 on the sf.net. > * Testing and coordination of testing across platforms and build systems. > > Anything else I've forgotten or people would like to see?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 2010/2012/2013 use .vcxproj and .vcxproj.filters files, so it's possible to have two sets of MSVS solution files: one for 2005/2008 and another for 2010/2012/2013. But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln (or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) What do you think? 2) VC projects contain relative paths such as "..\..\include". Is it better to leave them as is or to change to something like "$(SolutionDir)include"? 3) Currently there are two ia32 asm files (bitreader_asm.nasm and stream_encoder_asm.nasm) that are unused and not necessary to compile libFLAC: they offer no speed benefit and the corresponding functions were commented out (*after* the release of 1.3.0): http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 Is it better to remove these files from Makefile and .vcproj files, or to leave them? I don't think that they will become useful again, but who knows...
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 2010/2012/2013 use .vcxproj > and .vcxproj.filters files, so it's possible to have two sets of > MSVS solution files: one for 2005/2008 and another for 2010/2012/2013. > > But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln > (or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) > > What do you think?I think having 64 bit builds on Windows would be a good thing. Unfortunately since I don't have *any* Windows machines to even test on, zero recent experience on Windows and little desire to reaquaint myself with Windows this is not a job for me. However, I am more than happy to have someone else undertake this task, and will help where I can. As for what versions of MSVC we should support, I am not really qualified to say. What do other similar projects do? Eg Audacity? My main concern about having multiple build systems is the maintenance burden. As long as that burden is minor I'm happy to accept what people are willing to contribute. I personally will support the autotools based build system and can also support the Makefile.lite build system.> 2) > VC projects contain relative paths such as "..\..\include". Is it better to > leave them as is or to change to something like "$(SolutionDir)include"?That sounds like a good idea.> 3) > Currently there are two ia32 asm files (bitreader_asm.nasm and stream_encoder_asm.nasm) > that are unused and not necessary to compile libFLAC: they offer no speed benefit > and the corresponding functions were commented out (*after* the release of 1.3.0): > > http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 > http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 > > Is it better to remove these files from Makefile and .vcproj files, or to leave them? > I don't think that they will become useful again, but who knows...I think they should be deleted in a commit that says something like "Removing old nasm versions of some functions". That will clearly mark that commit so that if needed the files can be easily retrieved from the Git history. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
op 19-06-14 02:00, Erik de Castro Lopo schreef:> Hi all, > > [...] > > Anything else I've forgotten or people would like to see?Like I reported just before the release of 1.3.0 (mail of Fri, 05 Apr 2013 08:25:10 +0200, to be specific), compiling on Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of the type -Wcast-align.> CC lpc_intrin_sse2.lo > CC lpc_intrin_sse41.lo > CC md5.lo > md5.c: In function 'format_input_': > md5.c:282:25: warning: cast increases required alignment of > target type [-Wcast-align] > md5.c:288:24: warning: cast increases required alignment of > target type [-Wcast-align] > CC memory.lo > CC metadata_iterators.lo > [...] > CCLD libFLAC-static.la > make[4]: Leaving directory `/home/pi/bin/flac/src/libFLAC' > make[3]: Leaving directory `/home/pi/bin/flac/src/libFLAC' > Making all in flac > make[3]: Entering directory `/home/pi/bin/flac/src/flac' > CC analyze.o > CC decode.o > decode.c: In function ?write_callback?: > decode.c:971:28: warning: cast increases required alignment of > target type [-Wcast-align] > decode.c:972:28: warning: cast increases required alignment of > target type [-Wcast-align] > decode.c:973:28: warning: cast increases required alignment of > target type [-Wcast-align] > decode.c:974:28: warning: cast increases required alignment of > target type [-Wcast-align] > CC encode.o > encode.c:120:34: warning: cast increases required alignment of > target type [-Wcast-align] > encode.c:121:33: warning: cast increases required alignment of > target type [-Wcast-align] > CC foreign_metadata.o > CC main.o > CC local_string_utils.oOne other issue that I've brought up before but hasn't been fixed yet: none of the people that have contributed to FLAC in the last few years (save Miroslav) are in the AUTHORS file :)
Martijn van Beurden wrote:> One other issue that I've brought up before but hasn't been > fixed yet: none of the people that have contributed to FLAC in > the last few years (save Miroslav) are in the AUTHORS file :)flac-website Git is also slightly outdated (dead links, some text is obsolete, etc). Maybe it's time to update it too? And, doc/html/* in flac Git is even older.
On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote:>Erik de Castro Lopo wrote: > >> It sees that the most serious bug in the flac bug tracker: >> >> https://sourceforge.net/p/flac/bugs/413/ >> >> has been fixed in git. This fix alone is worth a new release so its >> time to work towards one. >> >> Things I need to do for this new release: >> >> * Deal with all current patches on the mailing list. >> * Review all bugs reported against 1.3.0 on the sf.net. >> * Testing and coordination of testing across platforms and build systems. >> >> Anything else I've forgotten or people would like to see? > >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 2010/2012/2013 use .vcxproj >and .vcxproj.filters files, so it's possible to have two sets of >MSVS solution files: one for 2005/2008 and another for 2010/2012/2013. > >But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln >(or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) > >What do you think? > > >2) >VC projects contain relative paths such as "..\..\include". Is it better to >leave them as is or to change to something like "$(SolutionDir)include"? > >3) >Currently there are two ia32 asm files (bitreader_asm.nasm and >stream_encoder_asm.nasm) that are unused and not necessary to compile libFLAC: >they offer no speed benefit and the corresponding functions were commented out >(*after* the release of 1.3.0): > > http://git.xiph.org/?p=flac.git;a=commitdiff;h=4eab6313cd2198b5647d925bdb3847590505fa21 > http://git.xiph.org/?p=flac.git;a=commitdiff;h=ecd0acba75e7961b60465c5ee3b6876b407803ca#patch14 > >Is it better to remove these files from Makefile and .vcproj files, or to >leave them? I don't think that they will become useful again, but who knows... >_______________________________________________Is it of any relevance, or perhaps already known, that libFLAC causes memory corruption when a METADATA_BLOCK_PICTURE block is larger than the allowed 16MB? This was just reported as crashing an application. I know that is an invalid block size, but just rejecting it would seem better. I haven't got metaflac to crash yet, although I did hang up my terminal on one attempt. --ian
On Thu, Jun 19, 2014 at 06:52:05PM +0200, Martijn van Beurden wrote:> One other issue that I've brought up before but hasn't been > fixed yet: none of the people that have contributed to FLAC in > the last few years (save Miroslav) are in the AUTHORS file :)Also, it would be nice to mention in the file that Erik is the current maintainer. :) -- Miroslav Lichvar
Erik de Castro Lopo wrote:> Things I need to do for this new release: > > * Deal with all current patches on the mailing list.Any patches pending? I have some bugfixes, and I'd like to make sure that they don't interfere with other fixes.
Martijn van Beurden wrote:> Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align.What happens if you change the definitions of s8buffer[] and ucbuffer_[] arrays as follows: static __attribute__((__aligned__(4))) FLAC__int8 s8buffer[FLAC__MAX_BLOCK_SIZE * FLAC__MAX_CHANNELS * sizeof(FLAC__int32)]; static __attribute__((__aligned__(4))) unsigned char ucbuffer_[CHUNK_OF_SAMPLES*FLAC__MAX_CHANNELS*((FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE+7)/8)]; ?
Martijn van Beurden wrote:> Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. > > > CC lpc_intrin_sse2.lo > > CC lpc_intrin_sse41.lo > > CC md5.lo > > md5.c: In function 'format_input_': > > md5.c:282:25: warning: cast increases required alignment of > > target type [-Wcast-align] > > md5.c:288:24: warning: cast increases required alignment of > > target type [-Wcast-align] > > CC memory.loDoes the test suite pass after you have compiled it?> One other issue that I've brought up before but hasn't been > fixed yet: none of the people that have contributed to FLAC in > the last few years (save Miroslav) are in the AUTHORS file :)I've pushed an update to that file. If anyone feels they or someone else has been left off that list, please let me know. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
lvqcl wrote:> Erik de Castro Lopo wrote: > > > Things I need to do for this new release: > > > > * Deal with all current patches on the mailing list. > > Any patches pending? I have some bugfixes, and I'd like to > make sure that they don't interfere with other fixes.I think I have those now (the 9 you posted in the last 12 or so hours). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/