similar to: object format detection

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

OK, I did the last few patches and made the source release. Hope I got everything. I'll send out the standard announcement now. Thanks everyone. Josh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

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

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/

--- configure.ac | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 36ac6c6..32bdd5f 100644 --- a/configure.ac +++ b/configure.ac @@ -103,9 +103,11 @@ esac AC_SUBST(OBJ_FORMAT) case "$host" in - *-*-cygwin|*mingw*) - # define this variable for enabling strict exports with libtool; for now, it's only supported by Win32

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

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

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 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. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo

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/

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

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. this one should have all the configure stuff working with the new assembly infrastructure. I have tried to make it as easy as possible to port routines to assembly. all that's really needed now is to write the corresponding routine for a specific

I am trying to set up a flexible infrastructure for the assembly code. 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. I know how to do the second, but what is a good way to do the first? Linux/Cygwin/Solaris seem to support the MACHTYPE

> > > $ aclocal && autoconf && automake -c -a -i > > > aclocal: configure.in: 45: macro `AM_PATH_XMMS' not found in > library > > > > my hunch is that your version of either automake or possibly > > autoconf is not recent enough. > > No. He simply doesn't have xmms installed. That's what I mentioned > a while ago:

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

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

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

> 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 did this for OpenBSD. NetBSD uses the same audio(4) system. It should also work on Solaris, but I can't test that. --- configure.in.orig Tue May 13 00:58:07 2003 +++ configure.in Tue May 13 00:58:20 2003 @@ -26,7 +26,7 @@ AC_CANONICAL_HOST AM_PROG_LIBTOOL AC_C_BIGENDIAN -AC_CHECK_HEADERS(sys/soundcard.h) +AC_CHECK_HEADERS(sys/soundcard.h sys/audioio.h) AC_ARG_ENABLE(ogg, [