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

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

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

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

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

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [flac-dev] 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. > >>

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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,