similar to: Testing needed

On 02/26/12 02:18 am, Erik de Castro Lopo wrote: > Hi all, > > I think we're getting close to the first FLAC release in over 4 > years. > > I have tested whats currently in Git on x86, x86_64 and PowerPC > Linux and would appreciate reports of successful compiles (and even > more importantly any failures) on OSX, Windows and elsewhere. Hi, build dies here on OS/2 as

LRN wrote: > f:/src/mingw-flac/flac-1.2.2-rc1/src/share/utf8/iconvert.c:175:5: > warning: passing argument 2 of 'libiconv' from incompatible pointer > type [enabled by default] > f:\mingw02\mingw-pc-i686\bin\../lib/gcc/mingw32/4.6.2/../../../../include/iconv.h:83:15: > note: expected 'const char **' but argument is of type 'char **' Firstly, what version of

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.02.2012 14:18, Erik de Castro Lopo wrote: > I ... would appreciate reports of successful compiles (and even > more importantly any failures) on ... Windows ... > 1) I have to update automake version from 1.7 to 1.11. This might be fixable with installing automake-1.7 for mingw, but i haven't bothered with that, and i prefer 1.11

Despite being documented as the place for submitting bug reports and patches, it seems like the sf.net bug tracker isn't get much attention, so here it is: http://sourceforge.net/p/flac/bugs/400/ During x86-windows builds using mingw or mingw-w64, nasm complains: nasm.h:83: warning: COFF section names limited to 8 characters: truncating I think the section .note.GNU-stack stuff aren't

Ok, I managed to compile the Ogg and Vorbis libs. Then, after modifying the file audio_out.c as follows: original: #include <dlfcn.h> modified: #include <win32/include/dlfcn.h> I was able to (finally!) compile libao. Then I tried to compile the module vorbis-tools, but uninvited problems came to my party. [...] > /usr/bin/ld: multiple definitions of symbol _getopt >

I'm looking at an issue reported by the Coverity static analyzer. In iconvert() in src/share/utf8/iconvert.c on line 152 there is newbuf = safe_realloc_add_2op_(utfbuf, ...); If the request size is not valid, the function will free utfbuf and return 0. This is followed by goto fail and utfbuf is freed for the second time. A simply fix would be to set utfbuf to 0 if newbuf is 0. However, this

1) Both src/share/Makefile.am and src/share/utf8/Makefile.am have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. Why? 2) What's the purpose of charsetmap.h? It seems that it's not used anywhere.

--- Ralph Giles <giles@xiph.org> wrote: > On Fri, Sep 14, 2007 at 02:51:34PM -0700, Josh Coalson wrote: > > > checked in to CVS is what will be very close to the 1.2.1 release > > of flac scheduled for monday. if anyone can try building it and > > even better running the test suite, and reporting back any > problems, > > that will help me get things in

Last night I checked in code to enable changing the object file format passed to nasm. But I don't have many examples to draw from so if anyone could submit patches against configure.in for any of nasm's supported formats I'll put them in. Right now the relevant snippet just looks like: AC_CANONICAL_HOST case "$host" in *) OBJ_FORMAT=elf ;; esac Any patterns for

Hi all, I have the following code, When I run the code, it never terminate this is because of the while loop i am using. In general, if you need a loop for which you don't know in advance how many iterations there will be, you can use the `while' statement so here too i don't know the number how many iterations are there. So Can some one suggest me whats going on? I am using the

The LLVM 2.6-compatible IR below is derived from the HLVM test suite and is one of the things I've noticed going wrong. However, I just discovered that it works with LLVM 2.6 and with LLVM SVN when run through lli or llc without -tailcallopt but when I use: $ llvm-as -f aout.ll $ llc -tailcallopt -f aout.bc -o aout.s $ gcc -lm aout.s -o aout and the latest LLVM SVN it starts to print

I was playing with optimization switches to llc to see how fast I could get it to compile but it keeps barfing. Tinkering indicates that llc barfs particularly when -tailcallopt is given in combination with other flags. For example, without -tailcallopt works in a couple of ways: $ llc -O0 -f aout.bc -o aout.s $ llc -O0 --regalloc=local -f aout.bc -o aout.s But fails with -tailcallopt with

On Nov 19, 2009, at 5:28 PM, Jon Harrop wrote: > > Are these barfs due to bugs in my generated code or is this parts of LLVM not > honoring tail calls? It was a bug in LLVM, with emitting tail calls at -O0. It's now fixed, as of r89444. Dan

For these simple compile tests where we want to ensure that a basic external program could be compiled using libnbd, we shouldn't include <config.h>. This is because we want to test here that <libnbd.h> can stand alone, without needing anything defined by the GNU autotools infrastructure. Of course we can use <config.h> in other test programs where we aren't evaluating

Hello everyone. Due to problems with libsndfile's handling of FLAC files, Mixxx is going to use libFLAC directly in v1.9.0. I'm the Windows packager and am trying to build libFLAC on Windows x64 using MSVC 2008 and the following steps that I've put together: http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac The problems I have are the following: If I try to build the

On Friday 20 November 2009 02:54:14 Dan Gohman wrote: > On Nov 19, 2009, at 5:28 PM, Jon Harrop wrote: > > Are these barfs due to bugs in my generated code or is this parts of LLVM > > not honoring tail calls? > > It was a bug in LLVM, with emitting tail calls at -O0. It's now > fixed, as of r89444. Awesome, thanks. What about this one where the simple register

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

Erik de Castro Lopo <mle+la at mega-nerd.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 01:47:01 +0300: >> 1) Both src/share/Makefile.am and src/share/utf8/Makefile.am >> have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. >> Why? > > EXTRA_DIST is for files that are not listed elsewhere in the Makefile.am > but which need to end up in the

Previously I wrote that precompute_partition_info_sums_32bit_asm_ia32_() only makes encoding slower. Now I managed to compile flac with GCC 4.8.1, with this function enabled and disabled. NASM was enabled, SSE intrinsics disabled. Then I added -msse option (so that all C code was compiled with -msse), then -msse2 and so on. Input file for test: 44.1kHz/16bit/stereo; best compression mode (flac

I have also asked this question on stackoverflow (http://stackoverflow.com/questions/8694676/compiling-64-bit-flac-libflac-in-os-x-lion), which you can answer if you're interested in reputation points. I am very unfamiliar with compiling C/C++ source of this size, and I'm having trouble debugging the issue. Basically, in the root folder of the FLAC bundle, even if I use the flags