similar to: patches for flac build

Displaying 20 results from an estimated 4000 matches similar to: "patches for flac build"

2004 Sep 10
2
1.0 candidate
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
2004 Sep 10
2
1.0 candidate checked in
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
2012 Dec 03
4
[PATCH 1/5] Remove old GNU-stack sections from nasm files.
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
2004 Sep 10
2
1.0 candidate checked in
> 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
2004 Sep 10
2
stat() and Windows
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
2004 Sep 10
0
1.0 source candidate
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
2004 Sep 10
2
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
2004 Sep 10
2
1.0 candidate checked in
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
2004 Sep 10
5
1.0 candidate checked in
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
2004 Sep 10
0
Re: detecting host machine in configure.in?
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
2004 Sep 10
1
XMMS plugin build fix
I think I sent a bad patch for this one already, which used a _LIBS variable. There is no _LIBS variable. :-) So, the .la file should be specified directly in _LIBADD, with no linker flag syntax. libtool will figure it out. diff -u -r1.1.1.1 Makefile.am --- Makefile.am 29 Jan 2001 18:13:29 -0000 1.1.1.1 +++ Makefile.am 21 Jun 2001 19:27:31 -0000 @@ -9,5 +9,5 @@
2004 Sep 10
2
XMMS plugin build fix
Damn, back to this thread: > I think I sent a bad patch for this one already, which used a _LIBS > variable. > There is no _LIBS variable. :-) So, the .la file should be specified > directly > in _LIBADD, with no linker flag syntax. libtool will figure it out. > > diff -u -r1.1.1.1 Makefile.am > --- Makefile.am 29 Jan 2001 18:13:29 -0000 1.1.1.1 > +++
2013 Aug 03
1
nasm.h issues (sf.net bug #400)
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
2004 Sep 10
2
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 elf
2004 Sep 10
0
XMMS plugin build fix
On Fri, Jul 20, 2001 at 01:06:53PM -0700, Josh Coalson wrote: > > xmmsinputplugin_LTLIBRARIES = libxmms-flac.la > > libxmms_flac_la_SOURCES = plugin.c > > -libxmms_flac_la_LIBADD = -L$(top_builddir)/src/libFLAC/.libs -lFLAC > > @XMMS_LIBS@ > > +libxmms_flac_la_LIBADD = @XMMS_LIBS@ > > $(top_builddir)/src/libFLAC/libFLAC.la > > libxmms_flac_la_LDFLAGS =
2004 Sep 10
1
plugin_xmms/Makefile.am incorrectly references .libs directory
When linking against a libtool library, you should simply specify it on the libtool command line as you would a library or an object file. Nothing should ever reference the .libs directory directly. diff -u -r1.1.1.1 Makefile.am --- Makefile.am 2001/01/29 18:13:29 1.1.1.1 +++ Makefile.am 2001/06/14 20:13:20 @@ -9,5 +9,6 @@ xmmsinputplugin_LTLIBRARIES = libxmms-flac.la
2004 Sep 10
0
1.0 candidate checked in
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? > >
2004 Sep 10
0
1.0 candidate checked in
--- 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
2004 Sep 10
2
1.0 candidate checked in
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:
2004 Sep 10
1
FLAC 1.0.4 beta released
--- Matt Zimmerman <mdz@debian.org> wrote: > On Tue, Sep 10, 2002 at 11:11:24PM -0700, Josh Coalson wrote: > > > 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. > > > > >