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") > set(CMAKE_FIND_LIBRARY_PREFIXES "lib" "") > > When I do that, I still get the same warning: > > libogg.exp : warning LNK4070: /OUT:ogg.dll directive in .EXP differs > from output filename > 'C:\Users\m_van\flac\build\objs\Release\libogg.dll'; ignoring > directive > > So, apparently either CMake or MSVC is forgetting to rename something, > somewhere. Does this help at all? https://github.com/xiph/ogg/pull/72 (Vorbis equivalent: https://github.com/xiph/vorbis/pull/76) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 already > been put in the changelog and README of the 1.3.4 release that they > will be removed) because that was already planned. CMake takes over > the role of providing a build system for Visual Studio. As recent > releases of Visual Studio actually feature integration of CMake, one > could see CMake as being 'endorsed' by Microsoft. Visual Studio users > will get a better maintained and configurable build system instead of > the rigid files flac provides right now. > > I'd also like to remove the Makefile.lite build system. From a remark > in the README it seems it was at some point created to provide an > alternative or back-up for the autotools build system, but a much more > flexible alternative is now available: CMake. > > I'd like to hear your thoughts on this matter. IMO, removal of both VS project files and Makefile.lite is OK. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 this patch?
>>
>> http://lists.xiph.org/pipermail/flac-dev/2017-January/006170.html
>>
>
> No. Lots of errors such as
> ../../include/FLAC/export.h:77:18: error: expected identifier or '(' before
> ')' token
> #define FLAC_API __declspec(__cdecl)
> ...
> as GCC doesn't like the __cdecl macro.
Well, you were the one who suggested __declspec(__cdecl)
(history for Eric: my original patch in the first mail in this thread
didn't have __cdecl, Dave wanted watcom and emx-gcc built
binaries to be compatible, so I suggested the second version.)
However, I see what's going on: gcc is possibly expecting the
calling convention specifier attribute between the type and the
funcname. (which can be fixed but in a way intrusive to all the
headers, such as by inventing and using a FLAC_CALL macro..)
>
> If going this route then perhaps,
>
> diff --git a/include/FLAC/export.h b/include/FLAC/export.h
> index d52f0bb..5d40421 100644
> --- a/include/FLAC/export.h
> +++ b/include/FLAC/export.h
> @@ -66,6 +66,13 @@
> #define FLAC_API __declspec(dllimport)
> #endif
>
> +#elif defined(__OS2__)
> +#if defined(FLAC_API_EXPORTS) && defined(__WATCOMC__) && defined(__SW_BD)
> +#define FLAC_API __declspec(__cdecl) __declspec(dllexport)
> +#else
> +#define FLAC_API __declspec(dllexport)
You had said that dllexport alone is not OK with emx-gcc, and
besides dllexport at that place is wrong: you want dllexport when
building flac as a dll (__SW_BD from Watcom tells us that and we
are sure because we defined FLAC_API_EXPORTS ourself.)
That line must either be calling convention (which you reported
fails with gcc) or it should be an empty define.
One solution is making that line an empty define for gcc and
__cdecl for Watcom.
> +#endif
> +
> #elif defined(FLAC__USE_VISIBILITY_ATTR)
> #define FLAC_API __attribute__ ((visibility ("default")))
>
> Another option is for the caller to define FLAC_API, eg
> #define FLAC_API __declspec(__cdecl)
> #include
>
> diff --git a/include/FLAC/export.h b/include/FLAC/export.h
> index d52f0bb..07cfe59 100644
> --- a/include/FLAC/export.h
> +++ b/include/FLAC/export.h
> @@ -56,6 +56,7 @@
> * \{
> */
>
> +#ifndef FLAC_API
> #if defined(FLAC__NO_DLL)
> #define FLAC_API
>
> @@ -66,6 +67,10 @@
> #define FLAC_API __declspec(dllimport)
> #endif
>
> +#elif defined(__OS2__)
> +#define FLAC_API __declspec(dllexport)
> +#endif
> +
> #elif defined(FLAC__USE_VISIBILITY_ATTR)
> #define FLAC_API __attribute__ ((visibility ("default")))
>
> @@ -73,7 +78,7 @@
> #define FLAC_API
>
> #endif
> -
> +#endif
> /** These #defines will mirror the libtool-based library version number,
> see
> *
> http://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning
> */
>
> This assumes that Ozkan isn't pursuing his OpenWatcom patches which isn't
> clear.
Well I'm bored. You guys decide.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
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/flac-dev/2017-January/006170.html ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
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(dllexport) though it still needs a def file, Eh?? > with no exports. Libtool doesn't currently and as flac uses libtool... > Dave Well that's a bummer. Anyways, with the changed exports.h patch, every need should be met now.. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
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 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.
>>>
>>
>> Disclaimer: I don't know much about EMX. That aside,
>>
>>> Most of the patches can have s/__EMX__/__OS2__/
>>
>> I intentionally kept __EMX__ checks because, IIRC, old gcc versions
>> (2.8?? can't remember) did define __EMX__ but not __OS2__
>
> Flac won't compile with old EMX, if only due to the lack of the stdint
> types. Pretty sure it's missing other math stuff as well.
I see (but keeping the EMX checks won't hurt either)
>
>>
>>> excepting the nasm.h one.
>>> nasm.h should test for OBJ_FORMAT_obj as obj is also correct when
>>> building with GCC flags -Zomf.
>>
>> OK, that can easily be added to configury, but..
>
> Please.
Will cook something for it,
>
>>
>>> Not sure about the assembly prefix as
>>> generally cdecl is correct for OS/2, perhaps test for defined
>>> (__WATCOMC__) && defined (__OS2__)
>>
>> Yeah: Default calling convention for Watcom is not __cdecl
>> it is, IIRC, __watcall and it doesn't prepend underscore to the
>> symbols
>
> Yes, why it should only be used by Watcom.
>
>>
>>>
>>> Will the GCC built flac8.dll link with Watcom with something like
>>> diff --git a/include/FLAC/export.h b/include/FLAC/export.h
>>> index d52f0bb..96d5422 100644
>>> --- a/include/FLAC/export.h
>>> +++ b/include/FLAC/export.h
>>> @@ -69,6 +69,9 @@
>>>#elif defined(FLAC__USE_VISIBILITY_ATTR)
>>>#define FLAC_API __attribute__ ((visibility ("default")))
>>>
>>> +#elif defined (__WATCOMC__) && defined (__OS2__)
>>> +#define FLAC_API __declspec(__cdecl)
>>> +
>>>#else
>>>#define FLAC_API
>>
>> As I said, I don't know much about emx, but the wrong thing
>> about the above is that it doesn't use dllexport therefore nothing
>> will be exported with this.
>
> It should work with an import library (untested), namely adding flac.lib
> to the linker directive for whatever is using flac8.dll.
> Just to be clear, I don't mean to recompile flac with the above patch,
> rather to install
> http://hobbes.nmsu.edu/h-search.php?button=Search&key=flac-1.3.2.zip&dir=%2F
>
> and patch the installed header as well as create the import library as
> below.
>
> R:\tmp>wlib flac.lib +FLAC8.dll
> Open Watcom Library Manager Version 2.0beta1 Limited Availability
> Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> Warning! Cannot open 'flac.lib' - library will be created
>
> Better would be for Flac to incorporate something like attached patch
> (needs testing) and add
> #define FLAC_API __declspec(__cdecl)
> before including FLAC/all.h
OK, I changed the patch to exports.h to be like the following:
diff --git a/include/FLAC/export.h b/include/FLAC/export.h
index d52f0bb..27b70af 100644
--- a/include/FLAC/export.h
+++ b/include/FLAC/export.h
@@ -57,7 +57,11 @@
*/
#if defined(FLAC__NO_DLL)
+#ifndef __OS2__
#define FLAC_API
+#else
+#define FLAC_API __declspec(__cdecl)
+#endif
#elif defined(_MSC_VER)
#ifdef FLAC_API_EXPORTS
@@ -66,6 +70,13 @@
#define FLAC_API __declspec(dllimport)
#endif
+#elif defined(__OS2__)
+#if defined(FLAC_API_EXPORTS) && defined(__WATCOMC__) && defined(__SW_BD)
+#define FLAC_API __declspec(__cdecl) __declspec(dllexport)
+#else
+#define FLAC_API __declspec(__cdecl)
+#endif
+
#elif defined(FLAC__USE_VISIBILITY_ATTR)
#define FLAC_API __attribute__ ((visibility ("default")))
It compiles with watcom OK. Apps link to it OK using watcom provided
that exports.h is changed like above. Using the same exports.h, apps
link to the import lib generated from the emx-compiled dll too.
Question: Does emx support __declspec(dllexport) so I can adjust
these changes? Because the emx build of the dll seems to have
exported _everything_ :(
--
O.S.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
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 I did >> not touch other places: If there is interest, I can do so. > > Patches that remove warnings of DJGPP compiler broke support > for Visual Studio 2005/2008. those patches weren't from me (for the record) > I don't care about these versions really, but I find it very > amusing that 20-years old and almost forgotten platforms > are more important than 10-years old. if you noticed something in these patches that breaks some other platform and/or compiler, please tell. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
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 it), therefore I did
>> not touch other places: If there is interest, I can do so.
>
Disclaimer: I don't know much about EMX. That aside,
> Most of the patches can have s/__EMX__/__OS2__/
I intentionally kept __EMX__ checks because, IIRC, old gcc versions
(2.8?? can't remember) did define __EMX__ but not __OS2__
> excepting the nasm.h one.
> nasm.h should test for OBJ_FORMAT_obj as obj is also correct when
> building with GCC flags -Zomf.
OK, that can easily be added to configury, but..
> Not sure about the assembly prefix as
> generally cdecl is correct for OS/2, perhaps test for defined
> (__WATCOMC__) && defined (__OS2__)
Yeah: Default calling convention for Watcom is not __cdecl
it is, IIRC, __watcall and it doesn't prepend underscore to the
symbols
>
> Will the GCC built flac8.dll link with Watcom with something like
> diff --git a/include/FLAC/export.h b/include/FLAC/export.h
> index d52f0bb..96d5422 100644
> --- a/include/FLAC/export.h
> +++ b/include/FLAC/export.h
> @@ -69,6 +69,9 @@
> #elif defined(FLAC__USE_VISIBILITY_ATTR)
> #define FLAC_API __attribute__ ((visibility ("default")))
>
> +#elif defined (__WATCOMC__) && defined (__OS2__)
> +#define FLAC_API __declspec(__cdecl)
> +
> #else
> #define FLAC_API
As I said, I don't know much about emx, but the wrong thing
about the above is that it doesn't use dllexport therefore nothing
will be exported with this.
>
> Not sure if a OMF import lib is required but easy enough to create with
> implib or emximp
> Dave
Don't know about this either. [The reason I choose Watcom over
emx/gcc is that I can compile on linux using Watcom, however the
emx stuff still aren't ported to linux making cross-compiling is not
possible and that's a big no for me.]
--
O.S.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[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. 0001-exports.h-properly-define-FLAC_API-when-building-a-d.patch Description: Binary data 0002-share-compat.h-properly-define-fseeko-ftello-and-FLA.patch Description: Binary data 0003-share-compat.h-add-__OS2__-to-list-of-cpp-checks-for.patch Description: Binary data 0004-metadata_iterators.c-add-__OS2__-to-the-list-of-cpp-.patch Description: Binary data 0005-bitreader.c-bitwriter.c-solve-the-inline-issue-for-W.patch Description: Binary data 0006-bitmath.h-provide-a-FLAC__clz_uint32-inline-asm-solu.patch Description: Binary data 0007-lpc.c-provide-a-solution-for-missing-lround-for-Watc.patch Description: Binary data 0008-ia32-nasm.h-for-Watcom-OS-2-asm-files-should-be-buil.patch Description: Binary data 0009-add-a-Watcom-makefile-to-build-an-OS-2-dll.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 of all [u]intNN_t types from share/compat.h >> into new file share/msvc2005_int.h and then includes this file >> into all files (via "Force Includes" option in *.vcproj files). >> >> The definitions of these types are inside #if block with >> _MSC_VER < 1600 condition, so these changes affect only MS Visual >> Studio compilers with _MSC_VER < 1600 (i.e. MSVS 2005 and 2008). > > Thats a really great solution to this problem. Applied! New file is not in the repo (you possibly forgot to 'git add' ) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] add missing string.h include to cpu.c (for memset())
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-in-cpu.c.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
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: >> > >> > Is `sizeof int == 4` though? >> >> Yes, obviously it is > > Well I've just pushed a patch that purges the code base of `unsigned`. > Please test and let us know how it goes. Well, the commit seems like overkill :) not all the unsigned needed converting. And build fails : format.c:53: error: conflicting types for 'FLAC__STREAM_SYNC' ../../include/FLAC/format.h:176: error: previous declaration of 'FLAC__STREAM_SYNC' was here [many others follow] ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
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't image FLAC working correctly > if it wasn't. > > Erik ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850: warning: passing arg 2 of `FLAC__bitreader_read_raw_uint32' from incompatible pointer type stream_decoder.c: In function `read_residual_partitioned_rice_': stream_decoder.c:2774: warning: passing arg 2 of `FLAC__bitreader_read_rice_signed_block' from incompatible pointer type stream_decoder.c:2783: warning: passing arg 2 of `FLAC__bitreader_read_raw_int32' from incompatible pointer type Apart from that, this also leads to format string warnings, e.g.: bitwriter.c:222: warning: unsigned int format, long unsigned int arg (arg 2) [many more, and in several sources.] This is just a FYI report. I don't have a patch for it. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 http://lists.xiph.org/mailman/listinfo/flac-dev
[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 http://lists.xiph.org/mailman/listinfo/flac-dev
[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 https://xiph.org/downloads/ still lists 1.3.1 for flac download. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Some additions for the 1.3.2 changelog?
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 this year. Perhaps some of these >> older >> ones are useful to consider including: > > > Wow, thanks for this. Really helpful to have someone else do something > I was dreading :). > > A couple of these I already had and the rest I added. Latest version > pushed to git. I suggest mentioning commit 1abd879 in the changelog too, i.e. "Assume that all OSes that are usable today support SSE." so that no one gets surprised. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 Audacity/Macports/Fink devs for comments? It compiles for i686-apple-darwin9 when applied to the current git. I also applied to a modified flac-1.3.0 decoder-only version, and it compiled and ran fine for me on Mac OS X 10.6.8. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 > > abs_residual_partition_sums[partition] = > (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); > > into this: > > movqQWORD PTR [rsi], xmm2 > > while it should be > > movdeax, xmm2 > mov QWORD PTR [rsi], rax > > With this patch, MSVC emits > > movqQWORD PTR [rsi], xmm2 > mov DWORD PTR [rsi+4], r9d > > so the price of this workaround is 1 extra write instruction per partition. Why not use a 64bit suffix to that 0x, e.g. 0xi64 to make the intention clear? (since you are specifically targeting msvc, the non-portability of i64 suffix shouldn't be a problem.) -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 peacefully. Please consider applying. -- O.S. diff --git a/configure.ac b/configure.ac index 99c471d..2ee2be0 100644 --- a/configure.ac +++ b/configure.ac @@ -380,8 +380,8 @@ fi XIPH_GCC_VERSION if test x$ac_cv_c_compiler_gnu = xyes ; then - CFLAGS="$CFLAGS -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code -Winline " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Wconversion - CXXFLAGS="$CXXFLAGS -Wall -Wextra -Wcast-align -Wshadow -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wsign-promo -Wundef -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Woverloaded-virtual -Wmissing-declarations + CFLAGS="$CFLAGS -Wall -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code -Winline " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Wconversion + CXXFLAGS="$CXXFLAGS -Wall -Wcast-align -Wshadow -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wsign-promo -Wundef -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Woverloaded-virtual -Wmissing-declarations XIPH_ADD_CFLAGS([-Wdeclaration-after-statement]) XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2]) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 @@ -437,6 +437,11 @@ if test x$enable_stack_smash_protection = "xyes" ; then XIPH_GXX_STACK_PROTECTOR fi +if test "x$sys_linux" = xtrue ; then + LIB_CLOCK_GETTIME=-lrt + fi +AC_SUBST(LIB_CLOCK_GETTIME) + AC_CONFIG_FILES([ \ Makefile \ src/Makefile \ diff --git a/microbench/Makefile.am b/microbench/Makefile.am index e00097d..452e748 100644 --- a/microbench/Makefile.am +++ b/microbench/Makefile.am @@ -36,3 +36,5 @@ noinst_HEADERS = util.h noinst_PROGRAMS = benchmark_residual benchmark_residual_SOURCES = benchmark_residual.c util.c + +benchmark_residual_LDADD = @LIB_CLOCK_GETTIME@ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] replace -Wextra with -W
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]), so >> this allows build using older compilers. > > Which older compilers do not support -Wextra? gcc-3.3 and older. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Two questions about RG in flac
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? >> ( and what is the version of your GCC? ) > I further reduced the testcase (attached). > > The bug only occurs if N >= 64; presumably the second loop is only SSE2 > optimized if that's the case. > > The problem seems to be that sum is interpreted as a 64 bit value if > SSE2 was used in the loop (the lower 32 bits of the result give the > expected value). If sum is evaluated another time before or after (!) > the printf, the problem goes away. For example, changing the last line > to "return sum + 1;" lets the problem disappear. > > I confirmed the bug with GCC 4.6.3 on Ubuntu. As on Windows, only 32 bit > code generation is affected. > > You should file a bug report with the GCC team. > With gcc-3,3,6, 3,4,6, 4.3.0 and gcc-4.9.1 (svn r210839) the output is normal: Sum = 64.00 (should be equal to 64) With gcc-4.8.3 (release version) it's broken: Sum = 206158430272.00 (should be equal to 64) With clang-3.4.1 (compiled with gcc-4.8.3) the output is normal again. This is on i686-linux (fedora9, glibc-2.8, kernel-2.6.27.35) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] XIPH_C_COMPILER_IS_CLANG preventing many flags
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 commit? > > The differences between GCC and Clang actually arose in the libsndfile > project. Full discussion here: > > https://github.com/erikd/libsndfile/issues/49 > > Erik > -- If the only offender is gcc-4.2 + -fgnu89-inline, something like the following, then?? diff --git a/configure.ac b/configure.ac index d3c302a..1c9557f 100644 --- a/configure.ac +++ b/configure.ac @@ -36,7 +36,6 @@ LT_INIT([win32-dll disable-static pic-only]) AM_PROG_AS AC_PROG_CXX XIPH_C_COMPILER_IS_CLANG -XIPH_GCC_REALLY_IS_GCC AC_PROG_MAKE_SET AC_PROG_MKDIR_P @@ -414,7 +413,7 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then CXXFLAGS="$CXXFLAGS -fvisibility=hidden" fi - if test "x$GCC_MAJOR_VERSION$GCC_MINOR_VERSION" = "x42" ; then + if test "x$GCC_MAJOR_VERSION$GCC_MINOR_VERSION" = "x42" && test x$xiph_cv_c_compiler_clang = xno ; then XIPH_ADD_CFLAGS([-fgnu89-inline]) fi -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
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 make it >> any more or any less dependent on any 'foreign' dlls: the patch doesn't >> change the existent situation in that regard. If I'm missing something, >> please explain. >> > > I don't know how all this autoconf machinery works, but if I want to > compile > flac.exe that requires only system libraries (kernel32.dll and msvcrt.dll) > then I simply use the following command: > > ./autogen.sh && ./configure --enable-static --disable-shared && make > > It worked earlier, and it works now with the current git sources. > In this case libFLAC.la contains the following lines: > > # The name that we can dlopen(3). > dlname='' > > # Names of this library. > library_names='' > > # The name of the static archive. > old_library='libFLAC.a' > > When ./configure is called without arguments, these lines contain: > > # The name that we can dlopen(3). > dlname='libFLAC-8.dll' > > # Names of this library. > library_names='libFLAC.dll.a' > > # The name of the static archive. > old_library='' > > So libFLAC.la can point either to dynamic or to static library. > OK, I see. Your problem is that static linkage doesn't work. To make it work with dllexport/import attributes, the configury and makefiles would need more massage as I explained: if there is interest, I may try it some time. > > * > Also: your patch adds the following lines to several Makefile.am files: > > if OS_IS_WINDOWS > win_utf8_lib = $(top_builddir)/src/share/win_utf8_io/libwin_utf8_io.la > endif > > zzz_LDADD = ... $(win_utf8_lib) ... > > On my system win_utf8_io is always a static library and is statically > linked > to the libFLAC library, so it's not necessary to explicitly link flac.exe > with libwin_utf8_io.la. libFLAC itself links to libwin_utf8_io.a. Without the dllexport attribs there is no need for those additions of mine. However with the patch in effect, the dll won't export them any longer and the extra linkage will become necessary. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] XIPH_C_COMPILER_IS_CLANG preventing many flags
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 http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
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), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) >> >> lvqcl, >> >> Can you please validate this new patch? > > It works, but only if i call ./configure without arguments. And it fails > if i call ./configure with "--disable-shared", "--enable-static" or > both "--disable-shared --enable-static". > Your configury already has the line LT_INIT([win32-dll disable-static pic-only]) ... so I took the assumption of dll builds are supported only. Your configury already has the line LT_INIT([win32-dll disable-static pic-only]) --disable-shared can be supported, but that would require some more major surgery: the flac build has a shared configury for both the library and the player, etc apps, therefore for the --disable-shared option to work, the CFLAGS must be added -DFLAC__NO_DLL (I think), but that would complicate the cases where both static and the shared libraries are built. > > (If I use ./configure without arguments then flac.exe requires > libFLAC-8.dll, > which in turn requires libgcc_s_sjlj-1.dll. Adding "--disable-shared" makes > flac.exe standalone: it doesn't need those libraries thst are foreign to > Windows systems). 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 or any less dependent on any 'foreign' dlls: the patch doesn't change the existent situation in that regard. If I'm missing something, please explain. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] extend visibility attributes usage to osx builds
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. > > Thanks Ozkan, > > Does this patch depend on the dllimport/dllexport patch? No, it is independent of it. > > Erik > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.com/ -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 b/configure.ac index 6d0fa00..cc5a247 100644 --- a/configure.ac +++ b/configure.ac @@ -392,8 +392,8 @@ fi XIPH_GCC_VERSION if test x$ac_cv_c_compiler_gnu = xyes ; then - CFLAGS="$CFLAGS -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Winline -Wconversion - CXXFLAGS="$CXXFLAGS -Wall -Wextra -Wcast-align -Wshadow -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wsign-promo -Wundef -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Woverloaded-virtual -Wmissing-declarations + CFLAGS="$CFLAGS -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Winline -Wconversion + CXXFLAGS="$CXXFLAGS -Wall -W -Wcast-align -Wshadow -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wsign-promo -Wundef -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Woverloaded-virtual -Wmissing-declarations XIPH_ADD_CFLAGS([-Wdeclaration-after-statement]) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 --- a/configure.ac +++ b/configure.ac @@ -395,7 +395,6 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then CFLAGS="$CFLAGS -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Winline -Wconversion CXXFLAGS="$CXXFLAGS -Wall -Wextra -Wcast-align -Wshadow -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Wsign-promo -Wundef -Wunreachable-code " # -Wcast-qual -Wbad-function-cast -Wwrite-strings -Woverloaded-virtual -Wmissing-declarations - XIPH_ADD_CFLAGS([-Wdeclaration-after-statement]) XIPH_ADD_CFLAGS([-D_FORTIFY_SOURCE=2]) @@ -409,6 +408,12 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then CXXFLAGS="$CXXFLAGS -fvisibility=hidden" fi + if test "$GCC_MAJOR_VERSION" -ge 4 && test "$OBJ_FORMAT" = macho; then + CPPFLAGS="$CPPFLAGS -DFLAC__USE_VISIBILITY_ATTR" + CFLAGS="$CFLAGS -fvisibility=hidden" + CXXFLAGS="$CXXFLAGS -fvisibility=hidden" + fi + if test "x$GCC_MAJOR_VERSION$GCC_MINOR_VERSION" = "x42" ; then XIPH_ADD_CFLAGS([-fgnu89-inline]) fi ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] make dllimport/dllexport attributes work with mingw (and others)
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 after this patch: > > format.c:47:22: error: variable 'FLAC__VERSION_STRING' definition is marked > dllimport > FLAC_API const char *FLAC__VERSION_STRING = VERSION; >^ > format.c:47:22: warning: 'FLAC__VERSION_STRING' redeclared without dllimport > attribute: previous dllimport ignored [-Wattributes] > format.c:49:22: error: variable 'FLAC__VENDOR_STRING' definition is marked > dllimport > FLAC_API const char *FLAC__VENDOR_STRING = "reference libFLAC " VERSION " > 20130526"; >^ > format.c:49:22: warning: 'FLAC__VENDOR_STRING' redeclared without dllimport > attribute: previous dllimport ignored [-Wattributes] > > ... > ... > > > FLAC_API_EXPORTS macro is defined in libFLAC_dynamic.vcproj, > FLACPP_API_EXPORTS macro is defined in libFLAC++_dynamic.vcproj, > but MinGW/GCC makefiles don't define them anywhere. 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), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) -- O.S. diff --git a/include/FLAC/export.h b/include/FLAC/export.h index 2232b41..185c282 100644 --- a/include/FLAC/export.h +++ b/include/FLAC/export.h @@ -59,11 +59,11 @@ #if defined(FLAC__NO_DLL) #define FLAC_API -#elif defined(_MSC_VER) -#ifdef FLAC_API_EXPORTS -#defineFLAC_API_declspec(dllexport) +#elif defined(_WIN32) +#if defined(FLAC_API_EXPORTS) || defined(DLL_EXPORT) +#define FLAC_API __declspec(dllexport) #else -#define FLAC_API _declspec(dllimport) +#define FLAC_API __declspec(dllimport) #endif #elif defined(FLAC__USE_VISIBILITY_ATTR) diff --git a/include/FLAC++/export.h b/include/FLAC++/export.h index 11c09e6..91649a5 100644 --- a/include/FLAC++/export.h +++ b/include/FLAC++/export.h @@ -59,11 +59,11 @@ #if defined(FLAC__NO_DLL) #define FLACPP_API -#elif defined(_MSC_VER) -#ifdef FLACPP_API_EXPORTS -#defineFLACPP_API _declspec(dllexport) +#elif defined(_WIN32) +#if defined(FLACPP_API_EXPORTS) || defined(DLL_EXPORT) +#define FLACPP_API __declspec(dllexport) #else -#define FLACPP_API _declspec(dllimport) +#define FLACPP_API __declspec(dllimport) #endif #elif defined(FLAC__USE_VISIBILITY_ATTR) diff --git a/src/flac/Makefile.am b/src/flac/Makefile.am index 389215e..a4929ab 100644 --- a/src/flac/Makefile.am +++ b/src/flac/Makefile.am @@ -44,6 +44,9 @@ flac_SOURCES = \ utils.h \ vorbiscomment.h +if OS_IS_WINDOWS +win_utf8_lib = $(top_builddir)/src/share/win_utf8_io/libwin_utf8_io.la +endif flac_LDADD = \ $(top_builddir)/src/share/utf8/libutf8.la \ $(top_builddir)/src/share/grabbag/libgrabbag.la \ @@ -51,7 +54,7 @@ flac_LDADD = \ $(top_builddir)/src/share/replaygain_analysis/libreplaygain_analysis.la \ $(top_builddir)/src/share/replaygain_synthesis/libreplaygain_synthesis.la \ $(top_builddir)/src/libFLAC/libFLAC.la \ - @LIBICONV@ \ + $(win_utf8_lib) @LIBICONV@ \ -lm CLEANFILES = flac.exe diff --git a/src/metaflac/Makefile.am b/src/metaflac/Makefile.am index d6e76e8..94fda50 100644 --- a/src/metaflac/Makefile.am +++ b/src/metaflac/Makefile.am @@ -42,12 +42,15 @@ metaflac_SOURCES = \ utils.h metaflac_LDFLAGS = $(AM_LDFLAGS) +if OS_IS_WINDOWS +win_utf8_lib = $(top_builddir)/src/share/win_utf8_io/libwin_utf8_io.la +endif metaflac_LDADD = \ $(top_builddir)/src/share/grabbag/libgrabbag.la \ $(top_builddir)/src/share/replaygain_analysis/libreplaygain_analysis.la \ $(top_builddir)/src/share/getopt/libgetopt.la \ $(top_builddir)/src/share/utf8/libutf8.la \ $(top_builddir)/src/libFLAC/libFLAC.la \ - @LIBICONV@ + $(win_utf8_lib) @LIBICONV@ CLEANFILES = metaflac.exe diff --git a/src/test_grabbag/cuesheet/Makefile.am b/src/test_grabbag/cuesheet/Makefile.am index a7fc5c5..134afb2 100644 --- a/src/test_grabbag/cuesheet/Makefile.am +++ b/src/test_grabbag/cuesheet/Makefile.am @@ -24,8 +24,13 @@ AM_CPPFLAGS = -I$(top_builddir) -I$(srcdir)/include -I$(top_srcdir)/include noinst_PROGRAMS = test_cuesheet test_cuesheet_SOURCES = \ main.c + +if OS_IS_WINDOWS +win_utf8_lib = $(top_builddir)/src/share/win_utf8_io/libwin_utf8_io.la +endif test_cuesheet_LDADD = \ $(top_builddir)/src/share/grabbag/libgrabbag.la \ + $(win_utf8_lib) \ $(top_builddir)/src/share/replaygain_analysis/libreplaygain_analysis.la \ $(top_builddir)/src/libFLAC/libFLAC.la diff --git a/src/test_grabbag/picture/Makefile.am b/src/t
[flac-dev] make dllimport/dllexport attributes work with mingw (and others)
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 supports this. Attached patch: declspec.diff Regards. -- O.S. diff --git a/include/FLAC/export.h b/include/FLAC/export.h index 2232b41..4b2418f 100644 --- a/include/FLAC/export.h +++ b/include/FLAC/export.h @@ -59,11 +59,11 @@ #if defined(FLAC__NO_DLL) #define FLAC_API -#elif defined(_MSC_VER) +#elif defined(_WIN32) /*defined(_MSC_VER)*/ #ifdef FLAC_API_EXPORTS -#defineFLAC_API_declspec(dllexport) +#define FLAC_API __declspec(dllexport) #else -#define FLAC_API _declspec(dllimport) +#define FLAC_API __declspec(dllimport) #endif #elif defined(FLAC__USE_VISIBILITY_ATTR) diff --git a/include/FLAC++/export.h b/include/FLAC++/export.h index 11c09e6..ab9b439 100644 --- a/include/FLAC++/export.h +++ b/include/FLAC++/export.h @@ -59,11 +59,11 @@ #if defined(FLAC__NO_DLL) #define FLACPP_API -#elif defined(_MSC_VER) +#elif defined(_WIN32) /*defined(_MSC_VER)*/ #ifdef FLACPP_API_EXPORTS -#defineFLACPP_API _declspec(dllexport) +#define FLACPP_API __declspec(dllexport) #else -#define FLACPP_API _declspec(dllimport) +#define FLACPP_API __declspec(dllimport) #endif #elif defined(FLAC__USE_VISIBILITY_ATTR) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH for cpu.c
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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] 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 needed for win32 and should possibly be disabled just as they are for aout. There are also warnings like: bitreader_asm.nasm:593: warning: label alone on a line without a colon might be in error cpu_asm.nasm:118: warning: label alone on a line without a colon might be in error fixed_asm.nasm:309: warning: label alone on a line without a colon might be in error lpc_asm.nasm:1508: warning: label alone on a line without a colon might be in error stream_encoder_asm.nasm:156: warning: label alone on a line without a colon might be in error ... all of which are for "end" and actually harmless (just annoying.) I suggest that .note.GNU-stack be limited to elf targets, like: diff --git a/src/libFLAC/ia32/nasm.h b/src/libFLAC/ia32/nasm.h index abd01c4..0ae887c 100644 --- a/src/libFLAC/ia32/nasm.h +++ b/src/libFLAC/ia32/nasm.h @@ -79,7 +79,7 @@ _%1: %1: %endmacro -%ifndef OBJ_FORMAT_aout +%ifdef OBJ_FORMAT_elf section .note.GNU-stack progbits noalloc noexec nowrite align=1 %endif And the thing is worse with OSX/x86 builds. Tried a linux-hosted cross- compile, got the following: nasm.h:83: panic: invalid section name .note.GNU-stack make[4]: *** [bitreader_asm.lo] Error 1 After commenting out line #83 of nasm.h, got the following: bitreader_asm.nasm:36: warning: label alone on a line without a colon might be in error bitreader_asm.nasm:43: warning: label alone on a line without a colon might be in error bitreader_asm.nasm:52: error: The Mach-O output format does not support any special symbol types bitreader_asm.nasm:593: warning: label alone on a line without a colon might be in error make[4]: *** [bitreader_asm.lo] Error 1 Notice that in both cases, the %error from line #54 of nasm.h does not trigger. The thing of course can be compiled by configuring --disable-asm-optimizations, no arguments there, but it would have been better if the configury had disabled it automagically. Regards. -- O.S. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
