similar to: libFLAC changes

Hey guys... a quick thought while we're in pre-v1.0 clean-up mode. Any thoughts to perhaps integrating a quick sector-boundary check of the wav file before encoding? Does this functionality extend beyond the scope of FLAC? A quick check, and a "this wav file is not cut on a sector boundary, continue y/n" warning would do the trick. Perhaps, an option to silence this check would

> Any thoughts to perhaps integrating a quick sector-boundary check of the > wav file before encoding? Does this functionality extend beyond the scope > of FLAC? A quick check, and a "this wav file is not cut on a sector > boundary, continue y/n" warning would do the trick. Perhaps, an > option to > silence this check would be useful also. > it's easy to

I just checked out the 1.0 candidate and ran autogen.sh autoconf errored out so autogen.sh did not work and I had to run automake manually. the autoconf error message was: configure.in:145: CFLAGS="$CFLAGS -fomit-frame-pointer -funroll-loops -finline-functions -Winline -DFLAC__INLINE=__inline__" anyhow I ran configure and I went into src/libFLAC/ia32 and ran gmake I get

Hello, I recently built FLAC 0.10 in NetBSD 1.5 i386 and had to make minor changes to the build configuration. Thanks for the awesome software! libtool would not link the "plain" nasm-generated object files for the i386 assembly optimizations. I've patched src/libFLAC/i386/Makefile.am to operate similarly to the automake file used for the SDL assembly routines. I saw a post to

On Fri, Jul 20, 2001 at 04:17:38PM -0400, Matt Zimmerman wrote: > Maybe the easy way to get around all of this is to build a plain old .a archive > for the assembler stuff, instead of a libtool .la library. This may or may not > cause problems when linking the libFLAC shared library. I'll try it. It does work, but gives a warning: *** Warning: Linking the shared library

Hi everybody, We have FLAC supported for input/output in REAPER (http://www.reaper.fm), and the problem is that when writing 24 bit FLAC files, the data isn't compressed (i.e. the FLAC is slightly larger than if it was writing to .WAV). The files play back fine, however, and 16 bit mode works great. We're using flac-1.1.2, built on win32 with MSVC6 w/ SP5 + VCPP, and NASM version 0.98.39

On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > So, last chance to checkout from CVS and break it! > > Also, my libtool doesn't seem to recognize --tag=CC. What is its purpose? > > /bin/sh ../../../libtool --tag=CC --mode=compile \ > sh ../../../strip_fPIC.sh nasm -f elf

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

Hi folks, here's a patch which cleans up the nasm call from Makefiles. Abusing libtool and then having to drop in some additional wrapper script to rewrite the commandline again is rather stupid. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/

> > libtool would not link the "plain" nasm-generated object files for > > the i386 > > assembly optimizations. I've patched src/libFLAC/i386/Makefile.am > > to operate > > similarly to the automake file used for the SDL assembly routines. > > > > I saw a post to the FLAC mailing list saying that automake expects > > the suffix >

On Thu, Jul 19, 2001 at 05:05:46PM -0700, Josh Coalson wrote: > --- collver@linuxfreemail.com wrote: > > On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > > > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > > > > > So, last chance to checkout from CVS and break it! > > > > > > Also, my libtool

On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote: > 2. Applied Matt's last cleanup patch of 8 files. I did not apply the patch > to src/test_unit/main.c since it looks wrong. main.c is supposed to include > the local bitbuffer.h, not src/libFLAC/private/bitbuffer.h; I think the > current version is correct. Ah, I missed that there was a local bitbuffer.h. In that

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

On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could

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

Matt Zimmerman <mdz@debian.org> wrote: > > > .SUFFIXES: .lo .s > > > .s.lo: > > > > (This of course doesn't work with automake.) > > It doesn't? Anything in a Makefile.am that doesn't appear to be special > automake magic is passed through to the Makefile (via Makefile.in). Yes, but... Hey, you're right. I thought I had

lvqcl wrote: > Audacity still uses VS2008 and slowly tries to migrate to VS2012. > But as stated at <http://wiki.audacityteam.org/wiki/Developing_On_Windows>, > "Audacity is currently a 32-bit only application". So it doesn't need > 64-bit builds. > Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008 > 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

On Wed, May 30, 2001 at 05:16:46PM +0000, Christian Weisgerber wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > I have checked in all the latest into CVS and am going to start the > > test suite again. if all goes well I will probably release this as > > beta 10. > > What's the sequence of steps required to turn this into a buildable >