Re: [flac-dev] How to change the dynamic library project name ogg to libogg?

On 6/7/23, Martijn van Beurden wrote: > I've added the following to Windows-MSVC.cmake, which I copied from > Windows-GNU.cmake > > set(CMAKE_IMPORT_LIBRARY_PREFIX "lib") > set(CMAKE_SHARED_LIBRARY_PREFIX "lib") > set(CMAKE_SHARED_MODULE_PREFIX "lib") > set(CMAKE_STATIC_LIBRARY_PREFIX "lib") >

Re: [flac-dev] Build systems to keep

On 5/1/22, Martijn van Beurden wrote: > Hi all, > > Currently flac has 4 build systems: autotools (configure.ac), CMake, > Makefile.lite and Visual Studio files. I think this is too much and > like some opinions on which to remove. > > I propose to remove the Visual Studio files (a mention has

Re: [flac-dev] os/2 support using Watcom

On 1/24/17, Dave Yeo wrote: > On 01/23/17 01:01 AM, Erik de Castro Lopo wrote: >> Dave Yeo wrote: >> >>> >GCC supports __declspec(dllexport) though it still needs a def file, >>> >with no exports. Libtool doesn't currently and as flac uses libtool... >> So you're happy with

Re: [flac-dev] os/2 support using Watcom

On 1/23/17, Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> Anyways, with the changed exports.h patch, every need should >> be met now.. > > > Sorry, which patch is that? > > Erik http://lists.xiph.org/pipe

Re: [flac-dev] os/2 support using Watcom

On 1/23/17, Dave Yeo <dave.r@gmail.com> wrote: > On 01/22/17 02:00 PM, Ozkan Sezer wrote: >> Question: Does emx support __declspec(dllexport) so I can adjust >> these changes? Because the emx build of the dll seems to have >> exported_everything_ :( > >

Re: [flac-dev] os/2 support using Watcom

On 1/22/17, lvqcl <lvqcl.m...@gmail.com> wrote: > Ozkan Sezer <seze...@gmail.com> wrote: > >> The attached set of patches adds support for OS/2 using Watcom compiler >> (tested with Open Watcom 1.9). My only interest was building a working >> dll (the l

Re: [flac-dev] os/2 support using Watcom

On 1/22/17, Dave Yeo <dave.r@gmail.com> wrote: > On 01/22/17 05:35 AM, Ozkan Sezer wrote: >> The attached set of patches adds support for OS/2 using Watcom compiler >> (tested with Open Watcom 1.9). My only interest was building a working >> dll (the last patch

[flac-dev] os/2 support using Watcom

The attached set of patches adds support for OS/2 using Watcom compiler (tested with Open Watcom 1.9). My only interest was building a working dll (the last patch in the set adds a makefile for it), therefore I did not touch other places: If there is interest, I can do so. Regards. -- O.S.

Re: [flac-dev] [PATCH] fix MSVC 2005/2008 build

On 1/18/17, Erik de Castro Lopo wrote: > lvqcl wrote: > >> > These versions of Visual Studio don't have stdint.h and >> > all [u]intNN_t types. But now these types are everywhere >> > in FLAC codebase. >> >> Here is the patch that fixes the problem: >> it moves definitions

Re: [flac-dev] [PATCH] add missing string.h include to cpu.c (for memset())

On 1/13/17, Ozkan Sezer <seze...@gmail.com> wrote: > Attached patch adds missing string.h include to cpu.c (for memset()) Simpler patch attached, which just replaces memory.h with string.h cpu.c was the only source to use memory.h instead of string.h. -- O.S. 0001-replace-memory.

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

On 1/14/17, Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> > Ozkan Sezer wrote: >> > >> >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> >> warnings with platforms (e.g. djgpp) where

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

On 1/14/17, Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> warnings with platforms (e.g. djgpp) where int32_t is long: > > Is `sizeof int == 4` though? Yes, obviously i

[flac-dev] unsigned int and FLAC__uint32 are used interchangeably

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer

[flac-dev] [PATCH] workaround for DJGPP missing wcswidth()

Attached patch works around for DJGPP missing wcswidth() in flac/utils.c:strlen_console() -- O.S. 0001-flac-utils.c-strlen_console-workaround-for-DJGPP-mis.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org

[flac-dev] [PATCH] add missing string.h include to cpu.c (for memset())

Attached patch adds missing string.h include to cpu.c (for memset()) -- O.S. 0001-add-missing-string.h-include-to-cpu.c-for-memset.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org

[flac-dev] [PATCH] support nasm coff obj format for djgpp

Attached patch adds support nasm coff obj format for djgpp -- O.S. 0001-support-nasm-coff-obj-format-for-djgpp.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC 1.3.2 has been released

On 1/3/17, Dave Yeo wrote: > On 01/02/17 11:43 PM, Erik de Castro Lopo wrote: >> Please let me know if any download.xiph.org/flac/ site is missing the >> 1.3.2 files. > > The Oregon State U, Open Source Lab mirror is still missing 1.3.2 > Dave Also, the xiph downloads page

Re: [flac-dev] [PATCH] for Darwin asm compile

On 6/12/16, lvqcl wrote: > This patch should fix https://sourceforge.net/p/flac/bugs/438/ > > I cannot test it myself because I don't have Mac OS X. > But the fact that such patch was included in Audacity means > that it should be OK. > > Or maybe it's better to ask

Re: [flac-dev] [PATCH] MSVC2015U2 workaround, version 2

On 5/2/16, lvqcl wrote: > Here's a new version of a patch that fixes a problem with MSVC2105 update2, > but it doesn't disable any optimization, so the resulting encoding > performance should be almost unaffected by this workaround. > > > MSVC compiles > >

[flac-dev] Wextra in configury

flac configury does a XIPH_ADD_CFLAGS([-Wextra]) around line 426, however it unconditionally adds -Wextra some lines before that too. The attached patch removes that unconditional addition of -Wextra which (i) removes duplicate addition, and (ii) allows older gcc versions to compile the tree

[flac-dev] microbench (benchmark_residual) requires -lrt for clock_gettime()

On my setup with glibc-2.8, benchmark_residual linkage fails with undefines references to clock_gettime(). Adding -lrt fixes that. The following is a small patch for it. Regards. -- O.S. diff --git a/configure.ac b/configure.ac index 993ac33..392485e 100644 --- a/configure.ac +++ b/configure.ac

Re: [flac-dev] replace -Wextra with -W

On 6/15/14, Erik de Castro Lopo mle...@mega-nerd.com wrote: Ozkan Sezer wrote: The attached small configury patch replaces -Wextra with -W in the main CFLAGS and CXXFLAGS assignments. A few lines after them, -Wextra is conditionally added already with XIPH_ADD_CFLAGS([-Wextra]), so

Re: [flac-dev] Two questions about RG in flac

On 6/3/14, Robert Kausch robert.kau...@freac.org wrote: Am 03.06.2014 16:45, schrieb lvqcl: 2) to ALL: I attached a small program. Compile and run it. * Does it work correctly when compiled with -O3 -msse2 options? * If yes, does it work correctly when compiled with -O3 -funroll-loops -msse2

[flac-dev] extend visibility attributes usage to osx builds

The attached small configury patch extends visibility attributes usage to darwin (osx) builds. Tested by cross-compiling on a linux host using gcc-.4.0.2 and gcc-4.2.1 against 10.4 and 10.6 SDKs. Regards. -- O.S. diff --git a/configure.ac b/configure.ac index 6d0fa00..d3c302a 100644 ---

[flac-dev] replace -Wextra with -W

The attached small configury patch replaces -Wextra with -W in the main CFLAGS and CXXFLAGS assignments. A few lines after them, -Wextra is conditionally added already with XIPH_ADD_CFLAGS([-Wextra]), so this allows build using older compilers. Regards. -- O.S. diff --git a/configure.ac

Re: [flac-dev] extend visibility attributes usage to osx builds

On 5/25/14, Erik de Castro Lopo mle...@mega-nerd.com wrote: Ozkan Sezer wrote: The attached small configury patch extends visibility attributes usage to darwin (osx) builds. Tested by cross-compiling on a linux host using gcc-.4.0.2 and gcc-4.2.1 against 10.4 and 10.6 SDKs. Thanks Ozkan

Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)

On 5/25/14, lvqcl lvqcl.m...@gmail.com wrote: Ozkan Sezer wrote: flac.exe built with mingw with or without the dllimport/dllexport patch always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it any more

Re: [flac-dev] XIPH_C_COMPILER_IS_CLANG preventing many flags

On 5/25/14, Erik de Castro Lopo mle...@mega-nerd.com wrote: Ozkan Sezer wrote: XIPH_C_COMPILER_IS_CLANG in configury (commit a6a4b6f) is blocking many flags including the visibility attributes: I guess this needs relaxing, possibly a lot. What incompatibility led to this commit

Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)

On 5/24/14, lvqcl lvqcl.m...@gmail.com wrote: Ozkan Sezer seze...@gmail.com писал(а) в своём письме Sat, 24 May 2014 10:16:15 +0400: - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after

Re: [flac-dev] PATCH for cpu.c

On 8/21/13, lvqcl lvqcl.m...@gmail.com wrote: 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. One may still compile using command line instead of a project file. Does it really hurt keeping