similar to: stat() and Windows

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