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
On 8/21/13, lvqcl 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 such code?
--
O.S.
_
The following patch changes export.h so that the dllimport/dllexport
attributes work with mingw/mingw-w64 and others:
- changes _declspec keyword to __declspec: the former may not be
defined by some toolchains.
- changes the _MSC_VER condition to universally _WIN32: MSVC, as well
as GCC support
On 5/24/14, lvqcl wrote:
> Ozkan Sezer писал(а) в своём письме 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 afte
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
--- a/configu
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 b/configu
On 5/25/14, Erik de Castro Lopo 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.
&g
On 5/25/14, lvqcl wrote:
> Erik de Castro Lopo wrote:
>
>> Ozkan Sezer wrote:
>>
>>> My apologies, obviously sent an old testing patch. Correct one is
>>> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5,
>>> binutils-2.20
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?
--
O.S.
___
flac-dev mailing list
flac-dev@xiph.org
h
On 5/25/14, lvqcl 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 ma
On 5/25/14, Erik de Castro Lopo 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 com
On 6/3/14, Robert Kausch 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 options?
>>
On 6/15/14, Erik de Castro Lopo 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]),
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
@
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 peac
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
>
> abs_residual_partition_sums[partitio
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 Audacity/Macports/Fink devs for
On 12/6/16, Erik de Castro Lopo wrote:
> MauritsVB wrote:
>
>> I noticed you’ve started compiling the changelog for 1.3.2.
>
> I had sort of hoped I'd finished :). Seems I was wrong!
>
>> I have kept track of some of the bigger changes since 1.3.1 although
>> admittedly haven’t been on top of it t
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 https://xiph.org/downlo
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
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
http://lists.xiph.org/mailman/listinfo/flac-de
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
http://lists.xiph.org
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 typ
On 1/14/17, Erik de Castro Lopo 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 it is
> I couldn
On 1/14/17, Erik de Castro Lopo wrote:
> Ozkan Sezer 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:
>> >
>
On 1/13/17, Ozkan Sezer 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.h-include-with-string.h
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 of all [u]intNN_t types
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.
0001
On 1/22/17, Dave Yeo 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 in the set adds a makefile for
On 1/22/17, lvqcl wrote:
> 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 in the set adds a makefile for it), therefore
On 1/22/17, Dave Yeo wrote:
> On 01/22/17 09:57 AM, Ozkan Sezer wrote:
>> On 1/22/17, Dave Yeo 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 Wat
On 1/23/17, Dave Yeo 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_ :(
>
> GCC supports __declspec(dllexpo
On 1/23/17, Erik de Castro Lopo 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/pipermail/
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 this patch?
>>
>>
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 alr
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")
> se
36 matches
Mail list logo