similar to: 1.0 source candidate

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

On Fri, Jul 20, 2001 at 05:15:21PM -0700, Josh Coalson wrote: > I rethought it and it seemed like a bad idea to post > a big file, so you can get it here: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/flac/junk/flac-1.0-src-candidate.tar.bz2 With the attached patch, a complete "make distcheck" should work, including the self-tests. It adds missing directories to some

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

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/

--- Christian Weisgerber <naddy@mips.inka.de> 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 > distribution? >

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

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

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

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 gang i'm about to start encoding lots of data (i.e. a 160 GB HDD full of wav files), and i'm having last minute hesitations about using a fairly new encoding program (flac). how much validation has been done on flac? in other words, apart from "it works", how can i trust that i'm not going to lose my data? i have seen at least one bug in the bug db where flac

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple

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 Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avoid this dependency by replacing flac_fopen() with fopen(). test_streams doesn't open/create

Without the following, nasm builds elf objects on cygwin and the build fails. (Though my cygwin packages are not very recent; would anyone else like to test this out?) Chris *** configure.in.orig Fri Feb 4 06:58:06 2005 --- configure.in Fri Feb 4 06:59:18 2005 *************** *** 52,57 **** --- 52,58 ---- AM_CONDITIONAL(FLaC__CPU_SPARC, test x$cpu_sparc = xtrue) case

All, I have just finished uploading the source release for FLAC 1.0.4 beta to Sourceforge; there are no binary releases. See the included doc/html/news.html for the changes since 1.0.3; there are quite a few. http://prdownloads.sourceforge.net/flac/flac-1.0.4_beta-src.tar.gz?download Please beat up on this as much as possible in the next week or two and try and turn up bugs. Here's a

> > For those of you using CVS, I have added a libFLAC section to the > > documentation page. I'm not sure how detailed to make it but I > > think it's a good start. Let me know if there's anything else > > you'd like to have in there. > > > > >

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

In order to compile flac-1.0 with Compaq C on FreeBSD/alpha, I needed to move -lm to the end of the libraries, otherwise ccc would complain about unresolved symbols. Patches below. The result is nothing less than stunning. On my 21164A/500 box, "ccc -fast" code is almost twice as fast as "gcc -O -mcpu=ev56", 1:11 vs. 2:03 for encoding a test track with default parameters.