Displaying 20 results from an estimated 300 matches similar to: "stat() and Windows"
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
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
2012 Jan 01
1
Compiling 64-bit libFLAC/libFLAC++ on OS X Lion, anyone successful?
I have also asked this question on stackoverflow (http://stackoverflow.com/questions/8694676/compiling-64-bit-flac-libflac-in-os-x-lion), which you can answer if you're interested in reputation points.
I am very unfamiliar with compiling C/C++ source of this size, and I'm having trouble debugging the issue. Basically, in the root folder of the FLAC bundle, even if I use the flags
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 Dec 03
0
[LLVMdev] [Fwd: Updated LLVM Visual Studio project files]
On Fri, 3 Dec 2004, Reid Spencer wrote:
> Could someone please apply this patch to the Win32 support so that
> Morten and Jeff can handle the recent changes? I can't do it because
> I"m on the road with only email access.
I'd be happy to do it. Can someone send me the patch as an attachment
off-list?
-Chris
> > <Tool
> >
2004 Sep 10
3
patches for flac build
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
2004 Dec 03
2
[LLVMdev] [Fwd: Updated LLVM Visual Studio project files]
Could someone please apply this patch to the Win32 support so that
Morten and Jeff can handle the recent changes? I can't do it because
I"m on the road with only email access.
Thanks,
Reid.
-----Forwarded Message-----
> From: Morten Ofstad <morten at hue.no>
> To: Reid Spencer <reid at x10sys.com>
> Subject: Updated LLVM Visual Studio project files
> Date: Thu,
2007 Oct 09
1
VC6 Patch
Here is a patch that gets the theora_static.dsp project for VC6 building
again.
Aaron
-------------- next part --------------
Index: win32/theora_static.dsp
===================================================================
--- win32/theora_static.dsp (revision 13945)
+++ win32/theora_static.dsp (working copy)
@@ -41,7 +41,7 @@
# PROP Intermediate_Dir "Static_Release"
# PROP
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
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
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 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
2009 Aug 05
2
FLAC 1.2.1 on OS X 10.4.11
hi,
according to the FAQ flac supports multichannel formats. i had no
luck with 1.1.4 though ( "Untitled.aif: ERROR: unsupported number
channels 8 for AIFF" ), i guess that feature was added in 1.2?
unfortunately, the binary for 1.2 does not run on OS X 10.4 (says
libiconv is too old). i removed libiconv and reinstalled that from
source, but then flac 1.2.1 just prints
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
1
checking OS support for SSE
Here is patch for checking OS SSE support for systems
having vfork()/fork() function.
Index: src/libFLAC/cpu.c
===================================================================
RCS file: /cvsroot/flac/flac/src/libFLAC/cpu.c,v
retrieving revision 1.8
diff -u -r1.8 cpu.c
--- src/libFLAC/cpu.c 2001/07/18 00:24:46 1.8
+++ src/libFLAC/cpu.c 2001/07/27 08:57:04
@@ -21,6 +21,20 @@
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
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
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.
> >
> >
>
2005 Sep 05
0
[LLVMdev] Pass is not automatically registered
Yes, unfortunately I am using the Visual C++ .NET compiler.
Morten Ofstad wrote:
> This problem is the motivation for having the _X86TargetMachineModule
> symbol in LLVM.
I thought this problem was solved by explictly list the object files
in the "Additional Dependencies" of the project file?
win32/llc/llc.vcproj:
2004 Sep 10
2
Re: beta 10 candidate checked in
On Thu, May 31, 2001 at 04:04:17AM -0400, Matt Zimmerman wrote:
> In order for all of this to work, of course, you need to make sure that
> automake knows which files should go in the distribution. Since it already
> knows about your source files, usually the only things that need to be added
> are random little files that aren't used directly in the build. These should
> be