similar to: Compile flac-1.1.1 on ppc Linux

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

I've had this a long time but haven't submitted it yet. I've tried to mirror the ia32 setup, so there should be a new subdirectory src/libFLAC/ppc . The first two attachments go there. The third is a context diff for src/libFLAC/Makefile.am . I have some more modified files, which I figured I'd submit after the above are checked in and working for somebody other than me. If you

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

thanks for the feedback, but it would really help if you supply a patch (diff -c), I didn't understand all the changes you described. someone reported a problem with src/libFLAC/include/private/lpc.h that was fixed in CVS and may fix the problem building with asm disabled http://cvs.sourceforge.net/viewcvs.py/*checkout*/flac/flac/src/libFLAC/include/private/lpc.h?rev=1.24 Josh --- Luca

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

On Mon, Jul 16, 2001 at 06:46:22PM -0400, Matt Zimmerman wrote: > [0] By the way, flac seems to segfault early on IA64. When built with > --enable-debug, I get a failed assertion: > > flac 0.10, Copyright (C) 2000,2001 Josh Coalson > flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are > welcome to redistribute it under certain conditions. Type

On Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

> > > Unfortunately, there is a bigger problem that affects both SDL > > > and FLAC, > > > which is that the assembly routines are not PIC. > > > > It's not? I think all the IA32 code only references data on the > > stack, and > > it doesn't call outside the library or export any functions outside > > the > > library. The

Has anyone tried to build flac with the INTEGER_ONLY_LIBRARY flag set lately? I'm getting link errors on IA32 for the SSE optimizations lpc_restore_signal_16_intrin_sse2 and lpc_restore_signal_wide_intrin_sse41. Looks like a define check is missing since the implementation of these functions is only included when not building for integer. I had to exclude them at libFLAC/stream_decoder.c:408

On 25.11.2014 12:14, Miroslav Lichvar wrote: > I think the case with non-zero partition order may need to be fixed > too. For example, with partition order of 1, predictor order of 16 and > blocksize of 4, the function would return true and blocksize-order in > the caller would still underflow. > > --- a/src/libFLAC/stream_decoder.c > +++ b/src/libFLAC/stream_decoder.c > @@

I tried to compile FLAC on Windows (the winamp2 plugin as a test) and I encoutered a problem. The stat() function and the associated structure doesn't exist on Windows (Visual Studio 5/6). But _stat and the structure with the same name does exist. So would it be possible to change stat() and struct stat ? I did the following in the code : #define STAT(x,y) _stat(x,y) typedef struct stat

I'm compiling FLAC 1.1.1 on Debian 3.0r3 with GCC 3.0 and nasm 0.98.28 on an AMD K6. # make [...] /bin/sh ../../../libtool --tag=CC --mode=compile sh ../../../strip_non_asm_libtool_args.sh nasm -f elf -d OBJ_FORMAT_elf -i./ lpc_asm.nasm -o lpc_asm.lo sh ../../../strip_non_asm_libtool_args.sh nasm -f elf -d OBJ_FORMAT_elf -i./ lpc_asm.nasm -fPIC -o .libs/lpc_asm.o nasm -f elf -d

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

--- John Steele Scott <toojays@toojays.net> wrote: > Josh Coalson <xflac@yahoo.com> writes: > > > --- John Steele Scott <toojays@toojays.net> wrote: > >> Back in October 2004, I did a bit of work on FLAC to get version > >> 1.1.1 to > >> build correctly under GNU/Linux/PPC. Only now have I realised that > >> somewhere > >>

Josh Coalson <xflac@yahoo.com> writes: > --- John Steele Scott <toojays@toojays.net> wrote: >> Back in October 2004, I did a bit of work on FLAC to get version >> 1.1.1 to >> build correctly under GNU/Linux/PPC. Only now have I realised that >> somewhere >> along the way something broke in FLAC's decoding. On my machine, >> roughly 50%

On Wed, May 23, 2001 at 03:18:16PM -0700, Josh Coalson wrote: > but since I'm not too saavy with autoconf/automake I'll ask for a little bit > more help. I think the only non-functional part left is that automake > doesn't support source files that are in subdirectories, relative to > Makefile.am(?) the layout in src/libFLAC/ is that all asm sources will go > under a

On Fri, Jul 20, 2001 at 03:01:54PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > > > automake will include ltmain.sh in the source distribution, so it > > should be > > used even if it isn't installed on the build system. In fact, it > > seems to > > always use the distributed version, and not the installed one

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

--- John Steele Scott <toojays@toojays.net> wrote: > Back in October 2004, I did a bit of work on FLAC to get version > 1.1.1 to > build correctly under GNU/Linux/PPC. Only now have I realised that > somewhere > along the way something broke in FLAC's decoding. On my machine, > roughly 50% > of FLAC files are being decoded incorrectly. > > I presume that I