similar to: FreeBSD 4.x problem resolved

Displaying 20 results from an estimated 600 matches similar to: "FreeBSD 4.x problem resolved"

2014 Mar 23
0
PATCH for cpu.c
Oliver St?neberg wrote: >> Unfortunately it breaks x86_64 build (where FLAC__CPU_X86_64 is defined, and >> FLAC__CPU_IA32 isn't). Maybe it's simpler to turn them into #defines such as >> >> #define FLAC__CPUINFO_IA32_CPUID_CMOV 0x00008000U >> #define FLAC__CPUINFO_IA32_CPUID_EXTENDED_AMD_3DNOW 0x80000000U >> >> and so on? > > Maybe
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
Altivec, automake
Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check
2014 Mar 22
2
PATCH for cpu.c
Hi, after having some discussion of the FPU/SSE behavior on the sf.net bug tracker as well as having some other changes we made for the MAME/MESS project sitting around I thought about joining this list to make things easier. First one is the latest modification we had to make to compile with clang 3.4 x64. Here are the warnings the 1.2.1 source will give with it:
2014 Mar 23
2
PATCH for cpu.c
> Oliver St?neberg wrote: > > > This is simply fixed by putting those unused constants into the > > proper defines. I attached a patch against git 70b078c. > > Unfortunately it breaks x86_64 build (where FLAC__CPU_X86_64 is defined, and > FLAC__CPU_IA32 isn't). Maybe it's simpler to turn them into #defines such as > > #define
2004 Sep 10
3
Altivec, automake
I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in
2016 Jun 21
2
FLAC__SSE_OS change
Erik de Castro Lopo wrote: > I actually think my change is correct. It should be easier to see if you > look at the github version of the change: > > https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 > FLAC__NO_SSE_OS was never defined anywhere, so I think that the following changes should be made:
2013 Aug 21
2
PATCH for cpu.c
1) Some time ago all project files for MSVC 6 were removed; it makes sense to remove the code that is necessary only for MSVC 6 and older compilers. --- a\src\libFLAC\cpu.c 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\cpu.c 2013-08-16 21:46:42.177485300 +0400 @@ -285,14 +285,7 @@ # ifdef USE_TRY_CATCH_FLAVOR _try { __asm { -# if _MSC_VER <= 1200 - /* VC6 assembler
2016 Jun 20
2
FLAC__SSE_OS change
About the commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6> I admit I don't understand the following lines: #if !FLAC__SSE_OS /* assume user knows better than us; turn it off */ disable_sse(info); #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ...... Probably it should be #if FLAC__SSE_OS /*
2014 Jun 01
2
Typos in the FLAC codebase
Erik de Castro Lopo wrote: >> 3) configure.ac, line 140: 'AM_CONDITIONAL(FLAC__CPU_X86_64, test "x$cpu_x86_64" = xtrue)' >> >> Not sure about this, but other names inside AM_CONDITIONALs begin with FLaC__, >> not FLAC__. A quote from configure.ac: "NOTE that for many of the AM_CONDITIONALs >> we use the prefix FLaC__ instead of FLAC__ since
2017 Feb 20
0
Flac build issue in debug win x32
Here is a patch that fixes the issue. There are multiple way to fix it though. Le 14/02/2017 à 15:08, Olivier Tristan a écrit : > Hi Guys, > > The following code in CPU.c (line 155) won't link if you don't have > NASM code built even if FLAC__HAS_X86INTRIN is true as > FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there > is no dead code
2012 Mar 23
0
Trying to link against libFLAC_static.lib (windows)
On 3/23/2012 13:59, Glenn McCord wrote: > Hi. I'm trying to get a project linking to libFLAC_static.lib but I > get linker errors such as the following. > > The __imp__ prefix seems to imply that some kind of .dll usage is > happening, which it shouldn't. > > All I need is the C lib, so I just build libFLAC_static from within > VS2010 (I've converted the
2012 Mar 23
2
Trying to link against libFLAC_static.lib (windows)
Hi. I'm trying to get a project linking to libFLAC_static.lib but I get linker errors such as the following. 6>AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved external symbol __imp__FLAC__stream_decoder_process_until_end_of_metadata referenced in function "protected: int __thiscall CFlacDecoder::CreateDecoder(void)" (?CreateDecoder at CFlacDecoder@@IAEHXZ)
2002 Apr 10
1
libao: FreeBSD OSS patchlet
machine/soundcard.h was only a compatibility symlink to sys/soundcard.h and just went away. >From Motoyuki Konno <motoyuki@bsdclub.org>. --- src/plugins/oss/ao_oss.c.orig Wed Apr 10 21:56:57 2002 +++ src/plugins/oss/ao_oss.c Wed Apr 10 21:57:11 2002 @@ -32,8 +32,6 @@ #include <math.h> #if defined(__OpenBSD__) || defined(__NetBSD__) #include <soundcard.h> -#elif
2015 Jan 08
0
[PATCH] Add ARM cpu detection for iDevices
On Jan 8, 2015, at 2:33 PM, Tom Hughes <tom at airtime.com<mailto:tom at airtime.com>> wrote: This adds run-time CPU detection for iOS devices. I found this page useful for CPU support and models: http://iossupportmatrix.com/ The patch could be simplified to just set the OPUS_CPU_ARM_NEON flag if you think it's unlikely that anyone would be running on the really old devices that
2016 Jun 23
0
FLAC__SSE_OS change
lvqcl wrote: > Erik de Castro Lopo wrote: > >> I actually think my change is correct. It should be easier to see if you >> look at the github version of the change: >> >> https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 >> P.P.S. 1) if FLAC__SSE_OS==1 then MSVC cannot compile current
2016 Jun 25
2
FLAC__SSE_OS change
lvqcl wrote: > 1) if FLAC__SSE_OS==1 then MSVC cannot compile current cpu.c: > "#include <windows.h>" line is inactive and MSVC complains: > cpu.c(278): error C2065: 'EXCEPTION_EXECUTE_HANDLER': undeclared identifier > cpu.c(279): error C2065: 'STATUS_ILLEGAL_INSTRUCTION': undeclared identifier > > 2) the current code (simplified): > >
2011 Mar 12
0
try with succes rpm bind 9.7.3 with koji el4 and el5
rehello centos list after some modifications rpm fedora core 14 of bind-9.7.3 and patching. diff -u unpatched/configure.in patched/configure.in --- unpatched/configure.in 2010-07-05 14:02:20.000000000 +0200 +++ patched/configure.in 2010-07-05 14:03:48.000000000 +0200 @@ -282,7 +282,8 @@ AC_C_INLINE AC_C_VOLATILE AC_CHECK_FUNC(sysctlbyname, AC_DEFINE(HAVE_SYSCTLBYNAME))
2000 Feb 27
0
[PATCH] Fix login.conf, expiration, BSD compatibility in OpenSSH
This patch revive almost all login.conf and password/account expiration features, makes OpenSSH more FreeBSD login compatible and fix non-critical memory leak. Please review and commit. --- sshd.c.old Fri Feb 25 08:23:45 2000 +++ sshd.c Sun Feb 27 02:53:33 2000 @@ -37,9 +37,8 @@ #endif /* LIBWRAP */ #ifdef __FreeBSD__ -#include <libutil.h> -#include <syslog.h> #define LOGIN_CAP
2012 Mar 25
2
Trying to link against libFLAC_static.lib (windows)
On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>