similar to: Compilation of flac-1.2.1 fails under MinGW

Displaying 20 results from an estimated 300 matches similar to: "Compilation of flac-1.2.1 fails under MinGW"

2012 Jun 24
3
Patch for cross compilation with MinGW32
Hello, I had some difficulties compiling the current git ( http://git.xiph.org/?p=flac.git;a=commit;h=a7e3705d051bafd1cae90f6605287cc1d9f2a18d ) using the Ubuntu 12.04 supplied MinGW32 cross compiler: I configured the FLAC build with --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux but ran into several linker problems. Are these options somehow wrong? It worked fine when
2007 Sep 11
2
include/share/alloc.h
Josh, I noticed the recent addition of the above file. In that file you have things like: static void *safe_malloc_(size_t size) { /* malloc(0) is undefined; FLAC src convention is to always allocate */ if(!size) size++; return malloc(size); } Did you meant to have an "inline" in there to make it: static inline void
2007 Sep 11
0
include/share/alloc.h
--- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > Josh, > > I noticed the recent addition of the above file. In that file you > have > things like: > > static void *safe_malloc_(size_t size) > { > /* malloc(0) is undefined; FLAC src convention is to always > allocate */ > if(!size) > size++; >
2013 Apr 06
2
Circular preprocessor define with MSVC
Hi, in include/share/alloc.h there is this section: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX SIZE_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX #endif So, if we are on MSVC and have neither SIZE_MAX nor SIZE_T_MAX, we'll define SIZE_T_MAX to mean SIZE_MAX and SIZE_MAX to mean SIZE_T_MAX. I'm afraid this won't work ... It
2008 Aug 13
4
MinGW Patch
Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX
2003 Sep 05
3
[Bug 458] sshd crashes with "fatal: mm_malloc: size too big"
http://bugzilla.mindrot.org/show_bug.cgi?id=458 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|IRIX |All Platform|MIPS |All ------- Additional Comments From dtucker at zip.com.au 2003-09-05 14:23
2008 Aug 13
0
MinGW Patch
will surgent wrote: > Hello, I was trying to compile Flac on MinGW/Msys but got an error stating > SIZE_T_MAX is undefined. > To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and > made the following change: <snip> > #ifndef SIZE_MAX > # ifndef SIZE_T_MAX > # ifdef _MSC_VER > # define SIZE_T_MAX UINT_MAX > # elif
2007 Sep 26
1
Patches for building of flac 1.2.1
Hello, We use two different patches to build flac. The first one is a patch that detects correctly ranlib, ac, strip when you cross-compile. We especially use the patch when compiling for Windows under GNU/Linux. http://trac.videolan.org/vlc/browser/trunk/extras/contrib/src/Patches/flac-cross.patch The other one fixes an issue when compiling for Windows under Cygwin, that can't find
2002 Aug 20
2
Solaris 7 w/ current CVS.
Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which we are now using in -current. OpenBSD defines it as ULONG_MAX. Pawing through the Solaris /usr/include it stated it could be 'u_int' or 'u_long'. Depends on if your are compiling legacy stuff. I'm sure other OSes may encounter this issue (not tried Linux, but Redhat 7.x does not define it), but what
2002 Dec 18
0
[Bug 458] New: sshd crashes with "fatal: mm_malloc: size too big"
http://bugzilla.mindrot.org/show_bug.cgi?id=458 Summary: sshd crashes with "fatal: mm_malloc: size too big" Product: Portable OpenSSH Version: 3.5p1 Platform: MIPS OS/Version: IRIX Status: NEW Severity: normal Priority: P3 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org
2011 Feb 08
1
Build issues and fixes
I've been putting some work into building Libflac into a game engine I'm working on. I ran into a few small issues in the process, and was able to fix them, so I thought I'd post with my fixes. These aren't generally applicable - I'm taking a "shortest path to functionality" approach - but with a little work could probably be turned into general patches. First,
2012 Apr 05
1
[PATCH] remove unnecesary typedef in bitwriter.c
--- src/libFLAC/bitwriter.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/src/libFLAC/bitwriter.c b/src/libFLAC/bitwriter.c index 651440d..7da4b15 100644 --- a/src/libFLAC/bitwriter.c +++ b/src/libFLAC/bitwriter.c @@ -43,12 +43,11 @@ /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this
2012 Feb 26
0
Testing needed
On 02/26/12 02:18 am, Erik de Castro Lopo wrote: > 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. Hi, build dies here on OS/2 as
2011 Sep 28
1
Compiling - Win - GNU Compiler
Hi, I went in big trouble compiling Flac (Windows). With configure (msys and mingw32-make 4.5.2) I didn't have success to compile. Makefile.lite the same. I used also the patches for SIZE_T_MAX UINT_MAX . Then I could compile every (!) project in flac with MSVC 2008 and I got all libraries, *.dll and *.exe. The libraries are passing all test-programs. With my own tools I see the *.dlls
2007 Nov 26
2
xmms-flac security update breaks XMMS' flac-playing ability
Hello, First post to this group. I've been searching for about a week now to find anyone who can solve this problem or point me to the solution. I've been a happy xmms-flac user for 4 years until this week when some new FLAC security updates came along and completely stopped XMMS from playing FLACs on my PC. This is most irritating as I have over 3,500 CDs ripped and FLAC'd in
2008 Oct 02
1
MinGW Patch
Erik de Castro Lopo wrote: > will surgent wrote: > > > Hello, I was trying to compile Flac on MinGW/Msys but got an error stating > > SIZE_T_MAX is undefined. > > To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and > > made the following change: Would it be possible to get this patch applied? I still hit this every time I try to
2009 Jul 11
4
[LLVMdev] LLVMdev Digest, Vol 61, Issue 25
Hi Anton, The problem is in getting the system configured. Below is the crash I get in configure. Your comment regarding gnuwin32 not being needed is interesting - I actually installed gnu bison/flex to get past an earlier crash in configure. Thats why I was suggesting that a precompiled OBJ_ROOT for MingW32 would be a good idea - configure appears to be inherently fragile, and requires more
2007 Nov 27
0
xmms-flac security update breaks XMMS' flac-playing ability
that missing symbol appears only in libFLAC 1.2.1 or later, so it sounds like the version dependencies in xmms-flac were not set up to automatically pull in 1.2.1. check the versions of the other flac packages on the machine (not sure what they're called in ubuntu but probably flac or libflac) and make sure they're up to 1.2.1 --- Myke Carter <mykec@mykec.net> wrote: > Hello,
2004 Mar 13
1
Ogg / Vorbis Compiling under W32 with MingW ** Problem **
I want to compile ogg and vorbis(version 1.01) under mingw. In the console i typed ./configure make but there is a lot of error while making. here is the errors $ ./configure checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific
2013 Mar 11
3
flac 1.3.0pre2 pre-release
Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from