similar to: 1.0 candidate checked in

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

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

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

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

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

> 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

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 Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

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

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

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

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

On Thu, Jul 19, 2001 at 02:56:11PM -0700, collver@linuxfreemail.com wrote: > On Thu, Jul 19, 2001 at 05:01:07PM -0400, Matt Zimmerman wrote: > > Once I removed that, it also seems to hate the .nasm extension: > > > > /bin/sh ../../../libtool --mode=compile \ > > sh ../../../strip_fPIC.sh nasm -f elf -d OBJ_FORMAT_elf cpu_asm.nasm > > libtool: compile:

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

On Fri, Jul 20, 2001 at 02:42:21PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > It does work, but gives a warning: > > > > *** Warning: Linking the shared library libFLAC.la against the *** static > > library ia32/libFLAC-asm.a is not portable! > > > > I think this is just because libtool can't determine whether the

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

--- Matt Zimmerman <mdz@debian.org> wrote: > 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

On Thu, Jul 19, 2001 at 05:01:07PM -0400, Matt Zimmerman 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 doesn't seem to recognize --tag=CC. What is its purpose? > >

Josh Coalson <xflac@yahoo.com> wrote: > it doesn't look like there's a provision for compiling .s files > with a different program than .c files, or even different flags. > so now I have no idea how to make this work as we would like. What again was our rationale for switching from .nasm to .s? <checks archive> Oh, I see, the automake/libtool magic for creating a

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