Re: [flac-dev] [PATCH] configure: only use -mstackrealign for mingw32

[JonY]

On 4/11/2015 05:10, Erik de Castro Lopo wrote:
 Tristan Matthews wrote:
 
 ---
  configure.ac | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/configure.ac b/configure.ac
 index eb9b0cc..e7d68c3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -399,9 +399,11 @@ if test x$ac_cv_c_compiler_gnu = xyes ; then
  
  if test x$asm_optimisation$sse_os = xyesyes ; then
  XIPH_ADD_CFLAGS([-msse2])
 -XIPH_ADD_CFLAGS([-mstackrealign])
  fi
 +fi
  
 +if test $host_os = mingw32 ; then
 +XIPH_ADD_CFLAGS([-mstackrealign])
  fi
  
  XIPH_ADD_CFLAGS([-Wextra])
 
 Everyone happy with this patch?
 
 Erik
 

This should only apply to i686 host 32bit mingw.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Can't cross-compile from git now.

[JonY]

On 3/9/2013 06:20, Erik de Castro Lopo wrote:
 bat guano wrote:
 

 Hi
 I have a problem now cross-compiling FLAC from latest git.
 With Ubuntu 12.04 and g++-mingw-w64-i686 (4.6.3-1ubuntu5+5ubuntu1).

 I think that the problem might have been introduced on 5 Mar 2013
 with commit 05609d5 (configure.ac : Add hardening compile options.)
 
 That was fixed with
 
 commit d5b03bcc36474ff1c9f2da2dcb5212e810208a6f
 Author: Erik de Castro Lopo er...@mega-nerd.com
 Date:   Sat Mar 9 08:55:37 2013 +1100
 
 configure.ac : Don't enable stack protector for mingw* host_os.
 

Hi,

Please do a link time test instead, I am not getting this error and
would like to keep stack protector on.

The test case below will trigger ___stack_chk_guard to emit.

int main(){
  int i = 0;
  char a[1000];
  while(1){
a[i] = 0;
i++;
  }
}

i686-w64-mingw32-gcc -D_FORTIFY_SOURCE=2 -fstack-protector --param
ssp-buffer-size=4 -v shows that libssp is already added.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] 2GB limit patch

[JonY]

On 3/5/2013 09:57, nu774 wrote:
 2. i686-pc-mingw also needs fseeko()/ftello() definitions (only 
 fseeko64() and ftello64() available).

Not true for i686-w64-mingw32, it has Linux style LFS64 with
_FILE_OFFSET_BITS.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] vsnprintf_s and vsnprintf

[JonY]

On 9/21/2014 08:17, lvqcl wrote:
 JonY wrote:
 
 You could just request mingw to include a vsnprintf_s implementation for
 XP and earlier, mingw-w64 has already done so.
 
 I use MinGW-w64: it's XhmikosR's MSYS that contains
 MinGW-w64 build of GCC/Binutils for Windows from nevcairiel.
 It has mingw-w64 3.1.0 inside.
 
 But I thought that MinGW-w64 links with msvcrt.dll and
 uses vsnprintf_s from it. Are you sure that MinGW-w64
 has its own independent implementation of vsnprintf_s?

No, it falls back on an internal implementation if it isn't found in
MSVCRT. And furthermore, I retract my statement after looking into the
implementation, it is just calling vsprintf while disregarding the size.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

[JonY]

On 5/5/2013 09:03, Timothy B. Terriberry wrote:
 Robert Kausch wrote:
 The _lseeki64 patch probably is a little more controversial. The problem
 is that fseeki64 and ftelli64 are not available in Windows XP - at least
 not without installing extra MSVC runtime libraries. I changed compat.h
 and replaced them with calls to _lseeki64, which was available at least
 back to Windows 98 and thus doesn't impose such compatibility issues.
 
 _lseeki64 operates on the underlying file handle, and does not interact 
 well with the buffering in stdio streams. I _think_ you can use this 
 successfully if you call fflush() beforehand (as this sets FILE::_cnt to 
 0 and FILE::_ptr to FILE::_base). By which I mean I read the MSVCRT 
 source from MSVC6.0 and it appears this is how things work.
 

How about just forgetting about base XP and require at least SP2 or some
such? Alternatively, use win32api underneath instead, eg
CreateFileW/SetFilePointer.

 That source also includes an fseeki64()/ftelli64(), but they are not 
 defined in stdio.h. I wonder if just declaring it yourself is good 
 enough? If not, they get called by fsetpos()/fgetpos() (which _do_ 
 interact correctly with the buffering in stdio streams), except when 
 _MAC is defined (which I presume is not common). I don't actually have 
 XP to test against.

Bad, do no declare manually, I had to cleanup some bad code recently
that make assumptions about your header declarations. You can try using
GetModuleHandle/GetProcAddress instead, but msvcr* versions are a whole
different can of worms.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/20/2013 00:35, Janne Hyvärinen wrote:

 As for calling __wgetmainargs, I have some concerns about the security
 implications:
 LoadLibrary(msvcrt.dll) - Which msvcrt? Theoretical security exploit.
 
 There is msvcrt.dll in the System32 dir in all supported Windows 
 systems. That is what the function targets, but of course LoadLibrary 
 searches from exe's dir first. I think security exploit concerns are 
 warrantless, if you can place malicious replacement c-runtime dll in the 
 exe's path you have already won.
 

Yeah, which is why I said it was theoretical.

I've seen code that use __ImageBase to over the import tables to find
out which MSVCR* DLL is used and use GetModuleHandleA to avoid LoadLibrary.


 I think it is best to link it directly, please use the following
 prototype and call it directly:

 =
 #ifdef _DLL
 #define CALL_DLLIMPORT __declspec(dllimport)
 #else
 #define CALL_DLLIMPORT
 #endif
 int __cdecl CALL_DLLIMPORT __wgetmainargs(int*, wchar_t***, wchar_t***,
 int, int*);
 =

 This should simplify the error handling logic and help against
 LoadLibrary handle leaks, though the leak should not be an issue in
 practice since it is only called once. The symbol should also be present
 in MSVCR* DLLs.
 
 This alone does nothing. It requires linking with an object file that 
 then deals with the function. If we link against msvcrt.lib the flac.exe 
 binary will no longer be static and it won't work without external 
 runtimes (which would also be loaded from the exe's dir if they exist 
 there). Linking with msvcmrt.lib won't find the function and unicode 
 version msvcurt.lib causes this error:
 Error1error LNK2005: ___iob_func already defined in 
 msvcurt.lib(MSVCR110.dll)G:\test\LIBCMT.lib(_file.obj)test
 Error2error LNK1169: one or more multiply defined symbols 
 foundG:\test\Release\test.exetest
 

There is no __wgetmainargs in the static libcmt? Interesting.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/18/2013 14:55, Erik de Castro Lopo wrote:
 Brian Willoughby wrote:
 
 I believe that shell does handle wildcards on all Unix variants,  
 including OSX.
 
 Yes.
 
 Since Windows does not handle them, I suggest that the  
 main flac code not be littered with code that's not necessary on the  
 primary platforms.
 
 No, the flac code will not be littered with code that's not necessary
 on the primary platforms.
 
 There will be some windows specific code in a new file, a bunch of
 replacements of existing fopen() calls with flac_fopen() (similarly
 for chmod and utime) and the main function for the flac and metaflac
 executables will have an additional:
 
 #ifdef _WIN32
   if (!convert_argv_to_utf8(argc, argv))
   flac__utils_printf(stderr, 1, ERROR: yada yada\n);
 #endif
 
 This is a small un-obtrusive change that I fully support.
 
 I would however like to see it sooner rather than later so we can get
 this damn thing released :-).
 

Before anyone does anything, see __wgetmainargs
http://msdn.microsoft.com/en-us/library/ff770599.aspx.

It can expand wildcards. Since it already provides argc/argv/env, it is
more a less a drop-in replacement for the main() arguments.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/18/2013 09:55, LRN wrote:
 On 18.03.2013 02:10, JonY wrote:
 On 3/17/2013 23:01, LRN wrote:
 All those ifdefs will at least be confined rather than spread
 out through the code.
 I did it plibc-style:

 in compat.h: #if defined(_WIN32) #define FOPEN
 grabbag__fopen_utf8_wrapper #else #define FOPEN fopen #endif

 in grabbag: #if defined(_WIN32) implement
 grabbag__fopen_utf8_wrapper, which has the same signature as
 fopen, but does utf8-utf16 conversion internally, then calls
 wfopen #endif

 and replace fopen with FOPEN everywhere else.
 
 Don't do that, it leaks into the system headers
 How? compat.h is not a public header, it is only used internally in
 FLAC. And i don't think that system headers have defines for FOPEN
 and such.
 

Preprocessor macros are not scoped. Even if FOPEN may not, but future
compat code that follow this pattern might easily bump into unrelated
identifiers. utime_uft8 already did some amount of damage.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/18/2013 19:21, Janne Hyvärinen wrote:
 On 18.3.2013 11:35, JonY wrote:
 Before anyone does anything, see __wgetmainargs
 http://msdn.microsoft.com/en-us/library/ff770599.aspx.

 It can expand wildcards. Since it already provides argc/argv/env, it is
 more a less a drop-in replacement for the main() arguments.
 
 MSVC also comes with
 http://msdn.microsoft.com/en-us/library/8bch7bkk%28v=vs.80%29.aspx. To
 support unicode with these methods would require somewhat more #ifdef
 code in main. We'd need to change project files to define Unicode
 character set and turn main into _wmain and char *argv to wchar_t *argv.
 Also these are MSVC's internal features, if I'm not mistaken. Other
 compilers on Windows would then require different solutions.
 

For setargv.obj, it is equivalent to doing int _dowildcard = 1; in any
linked object on mingw.

For wmain, regular mingw does not support it, but mingw-w64 does. The
issue is that the former is far more common in the wild.

I still prefer the __wgetmainargs approach, the exact same code can be
used for both mingw and msvc. We don't need to care about 9x, I think.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/18/2013 19:34, LRN wrote:
 On 18.03.2013 13:35, JonY wrote:
 Before anyone does anything, see __wgetmainargs 
 http://msdn.microsoft.com/en-us/library/ff770599.aspx.
 
 It can expand wildcards. Since it already provides argc/argv/env,
 it is more a less a drop-in replacement for the main() arguments.
 I can't find its version info. MSDN only documents it as far as VS2010
 (normal C functions are documented as far as VS2003), and it's not
 present in any header file i have.

I don't think it is, you probably required to declare it yourself.

The symbol is in the MSVCRXX runtime dll, all the way from MSVCRT.dll to
MSVC2012 MSVCR110. Suffice to say it is always there.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/17/2013 23:01, LRN wrote:
 All those ifdefs will at least be confined rather than spread out 
 through the code.
 I did it plibc-style:
 
 in compat.h:
 #if defined(_WIN32)
 #define FOPEN grabbag__fopen_utf8_wrapper
 #else
 #define FOPEN fopen
 #endif
 
 in grabbag:
 #if defined(_WIN32)
 implement grabbag__fopen_utf8_wrapper, which has the same signature
 as fopen, but does utf8-utf16 conversion internally, then calls wfopen
 #endif
 
 and replace fopen with FOPEN everywhere else.

Don't do that, it leaks into the system headers and breaks mingw if
FLAC_USE_FOPEN_UTF8 is defined.

Call the wrappers directly instead of using a macro.



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

[JonY]

On 3/17/2013 10:33, Janne Hyvärinen wrote:
 Here's a patch that makes MSVC compiled flac.exe able to use wildcards
 and encode/decode files with Unicode characters in names. It may not be
 the prettiest code but it fulfills its primary purpose.
 I tried to alter FLAC code as little as possible. It replaces argv with
 utf-8 encoded version and only converts to usable Unicode for file
 functions. That means printed texts and tags that contain non-ascii
 characters will be broken, but it is fixable if these changes are
 acceptable.
 

Can this be reworked without the defines? This way, it should support
mingw builds too.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Can't cross-compile from git now.

[JonY]

On 3/13/2013 06:50, Erik de Castro Lopo wrote:
 JonY wrote:
 
 Dave, my toolchain automatically links libssp already, I am using
 vanilla sources.
 
 Are you doing a native Windows compile with MinGW or cross compiling
 from Linux?
 

Crossing from Cygwin, GCC built from vanilla FSF sources.

 Why not also check if -lssp is required? If the toolchain has SSP
 disabled it should not be passing. Check onces without -lssp and another
 time with -lssp if it failed.
 
 If we can easily force the linking of libssp then that maky work. I'm
 not real keen on having the Windows DLL require this extra libssp-X.dll.
 

I guess that's libtool doing it. The link test that I used certainly did
not require the DLL.

 Also, I don't think a trivial hello world will cause SSP code to be
 emitted, try adding some arrays in stack with a deliberate overrun
 possibility for the link test.
 
 Unfortunately its even more complicated than that. It can sucessfully
 link and create a valid executable (with and without -lssp) which then
 fails at run time because it can't find libssp-0.dll. 
 

Libtool forces all DLL code to link to other DLLs.

 This stuff is broken. I cannot see any reasonable way to make this
 work across the board. The best option I can suggest is a 
 
 ./configure --enable-stack-smash-protect
 
 which is disabled by default.
 

I am OK with this.





signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Can't cross-compile from git now.

[JonY]

On 3/12/2013 18:58, Erik de Castro Lopo wrote:
 Erik de Castro Lopo wrote:
 
 JonY wrote:

 Please do a link time test instead, I am not getting this error and
 would like to keep stack protector on.

 I'll write an m4 macro.
 
 I have attampted to write a macro that reliably detects the availability
 of stack smash protection.
 
 I currently have two configurations where my detection says that SSP is
 available but the compile fails:
 
  - MinGW cross compile from Linux to Windows.
  - Native FreeBSD compile.
 
 Not sure what to do from here. I think I'll probably have to disable
 this for this upcoming release.
 

What is your link test checking and how does it fail?




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Patch for cross compilation with MinGW32

[JonY]

On 6/24/2012 10:23, Christoph Terasa wrote:
 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 I
 compiled libogg-0.dll. Anyway, I attached a patch to allow cross
 compilation with MinGW32 on my machine again:
 
 First, I moved the implementation of *safe_malloc_mul_2op_ to alloc.h,
 just like all the other alloc implementations, and removed the thereby
 obsolete alloc.c implementation from grabbag.
 Second, I just wrapped FLAC__clz_soft_uint32 with an #ifndef __MINGW32__.

Curious, why is FLAC__clz_soft_uint32 needed?




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Trying to link against libFLAC_static.lib (windows)

[JonY]

On 3/26/2012 06:52, Glenn McCord wrote:

 Did you compile the dll earlier? If so, you can try cleaning the project
 and rebuilding.
 
 I've compiled the .dll earlier, but they've now all been deleted. They
 would have been built when I built the entire solution (and thus all
 the projects). I've subsequently deleted them and just built the
 libFLAC_static.lib
 
 I've previously installed the FLAC for windows with installer from
 the flac website, but I've since deleted that too. There are no flac
 libraries anywhere on my machine now except for that single
 libFLAC_static.lib that has been built.
 

I'm not very familiar with MSVC, but I was suggesting cleaning out all
the temporary files too, not just the dll/lib end targets.


 If not, you'd need to look into the headers, check where those problem
 functions are defined. Finally, you'll need to trace back any macros
 that might be potentially using __declspec(dllimport).
 
 Just to be sure, I went to export.h and exlicitly defined FLAC_API and
 commented out the lines
 
 #ifdef FLAC_API_EXPORTS
 #define   FLAC_API_declspec(dllexport)
 #else
 #define FLAC_API  _declspec(dllimport)
 
 I've so cleaned and rebuilt all my project files but still get the errors:
 
 11AudioDecoder.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@CFlacDecoder@@IAEHXZ)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_init_file referenced in
 function protected: int __thiscall CFlacDecoder::CreateDecoder(void)
 (?CreateDecoder@CFlacDecoder@@IAEHXZ)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_init_ogg_file referenced
 in function protected: int __thiscall
 CFlacDecoder::CreateDecoder(void)
 (?CreateDecoder@CFlacDecoder@@IAEHXZ)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_new referenced in function
 protected: int __thiscall CFlacDecoder::CreateDecoder(void)
 (?CreateDecoder@CFlacDecoder@@IAEHXZ)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2001: unresolved
 external symbol __imp__FLAC__StreamDecoderStateString
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_get_state referenced in
 function int __cdecl die_s_(char const *,struct FLAC__StreamDecoder
 const *) (?die_s_@@YAHPBDPBUFLAC__StreamDecoder@@@Z)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2001: unresolved
 external symbol __imp__FLAC__StreamDecoderErrorStatusString
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_delete referenced in
 function public: virtual __thiscall
 CFlacDecoder::~CFlacDecoder(void) (??1CFlacDecoder@@UAE@XZ)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_flush referenced in
 function public: int __thiscall CFlacDecoder::Seek(unsigned int)
 (?Seek@CFlacDecoder@@QAEHI@Z)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_seek_absolute referenced
 in function public: int __thiscall CFlacDecoder::Seek(unsigned int)
 (?Seek@CFlacDecoder@@QAEHI@Z)
 11AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved
 external symbol __imp__FLAC__stream_decoder_process_single referenced
 in function public: int __thiscall CFlacDecoder::DecodeFrame(void)
 (?DecodeFrame@CFlacDecoder@@QAEHXZ)
 11.\Debug/ScratchLIVE.exe : fatal error LNK1120: 11 unresolved externals
 
 Could there be some setting that I've got incorrect or incompatible
 between the FLAC project and the project that is using it?
 

From the looks of the above macro, you should #define FLAC_API to
nothing. Perhaps you could try searching deeper if FLAC_API was doubly
defined elsewhere.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Trying to link against libFLAC_static.lib (windows)

[JonY]

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 VS2005 project)
 
 I've then linked to that library by setting the linker settings
 General- Additional Library Dependencies and Input- Additional
 Dependencies appropriately.
 
 Both the main app and the flac libs are build using the runtime
 library Multi-Threaded /MT (or /MTd for debug mode)
 

That is the MSVCR* library settings.

 The flac project is using the preprocessor definitions:
 
 WIN32
 NDEBUG
 _LIB
 FLAC__HAS_OGG
 FLAC__CPU_IA32
 FLAC__HAS_NASM
 FLAC__USE_3DNOW
 VERSION=1.2.0
 FLAC__NO_DLL
 
 I'm not sure what else to try at this stage. I've reached the point
 where I start going in circles and accessing the same internet search
 results. Has anyone got any suggestions?
 

Did you compile the dll earlier? If so, you can try cleaning the project
and rebuilding.

If not, you'd need to look into the headers, check where those problem
functions are defined. Finally, you'll need to trace back any macros
that might be potentially using __declspec(dllimport).



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH] Remove even more CPP hackery

[JonY]

On 2/10/2012 02:14, LRN wrote:
 On 09.02.2012 21:41, Ben Allison wrote:
 Dave Yeo wrote:
 Yes that makes sense. Requiring a C99 compliant compiler
 seems quite
 reasonable.
 Well I'm actually going to be even more reasonable than that.
 The only
 bits of C99 that flac will really require is header file
 with C99 standard width integers (int8_t, uint8_t, int16_t
 etc). Erik

 I would recommend including with the distribution a file for
 windows developers to use.  It's fairly simple


 /* since windows doesn't have stdint.h */ typedef unsigned
 __int64 uint64_t; typedef unsigned __int32 uint32_t; typedef
 unsigned __int16 uint16_t; typedef unsigned __int8 uint8_t; 
 typedef __int64 int64_t; typedef __int32 int32_t; typedef __int16
 int16_t; typedef __int8  int8_t; #if defined(_M_IX64) typedef
 unsigned __int128 uint128_t; typedef __int128 int128_t; #endif
 
 Also, I agree with the consensus that developers have to #include
 such a file before using including FLAC/all.h This is because many
 Windows developers (such as myself) are likely to already have a
 stdint.h replacement defined somewhere in their project. The other
 choice would be to see if there's some preprocessor symbol commonly
 in use that would indicate that these are defined by the compiler 
 or by preprocessor directives.
 Please, exclude us, MinGW users, from this. MinGW comes with stdint.h

Likewise for MSVC 2010 users. I still sigh a lot when developers assume
Windows == MSVC.



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH] Remove even more CPP hackery

[JonY]

On 2/8/2012 03:33, Dave Yeo wrote:
 On 02/07/12 12:03 am, Erik de Castro Lopo wrote:
 Dave Yeo wrote:

 This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been
 been replaced by klibc. Considering the age of EMX and lack of testing
 and that klibc contains so many improvements I think this is exceptable.

 Sorry Dave, I can't do that. Or rather sorry, the patch doesn't apply.
 Probably a line wrapping issue. Maybe you should try send it as an
 attachment.

 
 Another try
 Dave
 
 

Why is inttypes.h using OS ifdefs? Shouldn't it be HAVE_INTTYPES_H?



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH 2/2] OS/2 EMX natively uses AOUT so pass -f aout to NASM

[JonY]

On 2/5/2012 16:01, Erik de Castro Lopo wrote:
 JonY wrote:
 
 On 2/5/2012 13:30, Erik de Castro Lopo wrote:
 Dave Yeo wrote:

 ---
  configure.ac |1 +

 Both applied (first with a minor tweak). Thanks.

 Erik

 Unfortunately, this steps on my patch. Updated patch attached. Cygwin
 really shouldn't be calling win32 API.

 On the otherhand, I can't seem to find any ntohl use(???).
 
 Yeah, I've got a patch in an un-merged branch that purges MINGW_WINSOCK_LIBS
 and reduces the LT_NO_UNDEFINED section to:
 
 case $host in
   *-*-cygwin|*mingw*|*emx*)
   # define this variable for enabling strict exports with
 # libtool; for now, it's supported by Win32 and OS/2
   LT_NO_UNDEFINED=-no-undefined
   ;;
   *)
   LT_NO_UNDEFINED=
   ;;
 esac
 AC_SUBST(LT_NO_UNDEFINED)
 
 which should please everyone :-).

Looks good.




signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Moving CPP hackery

[JonY]

On 2/4/2012 13:20, Erik de Castro Lopo wrote:
 Hi all, especially David Yeo and JonY,
 
 I've started moving compiler specific CPP hacker into a separate file
 at include/share/compat.h.
 
 Eventually I hope to be able to move all of the require CPP hackery
 for $random_compiler into this file and have any C file which needs
 any compiler specific tweak to include this new compatibilty header.
 
 My belief is that one this CPP hackery is all in one place, it will
 be far easier to modify and keep correct.
 
 So, I would be very greatful if David Yeo and JonY could test current
 git HEAD and provide a patch if anything breaks. I will hold off
 on any further hacking for a couple of days to give you guys time to
 test this.
 

Hi,

Looks like there are some missed defines in the test_libFLAC++. Attached
patch fixes that.

Also, wsock32 usage is deprecated, on Win7, wsock32 forwards everything
to ws2_32, suggest changing to -lwsock32 to -lws2_32 in configure.ac.
Additionally, using -lwsock32 on Cygwin is wrong. Fix in config.txt.

I also suggest changing all the switch-case statements in configure.ac
to AS_CASE.
diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
index 0323d73..67654b8 100644
--- a/src/libFLAC/stream_decoder.c
+++ b/src/libFLAC/stream_decoder.c
@@ -46,16 +46,7 @@
 #include string.h /* for memset/memcpy() */
 #include sys/stat.h /* for stat() */
 #include sys/types.h /* for off_t */
-#if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
-#if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
-#ifndef fseeko
-#define fseeko fseek
-#endif
-#ifndef ftello
-#define ftello ftell
-#endif
-#endif
-#endif
+#include share/compat.h
 #include FLAC/assert.h
 #include share/alloc.h
 #include protected/stream_decoder.h
diff --git a/src/test_libFLAC++/decoders.cpp b/src/test_libFLAC++/decoders.cpp
index 4398887..f7f5a42 100644
--- a/src/test_libFLAC++/decoders.cpp
+++ b/src/test_libFLAC++/decoders.cpp
@@ -24,17 +24,12 @@
 #include stdio.h
 #include stdlib.h
 #include string.h
-#if defined _MSC_VER || defined __MINGW32__
-#if _MSC_VER = 1600 /* @@@ [2G limit] */
-#define fseeko fseek
-#define ftello ftell
-#endif
-#endif
 #include decoders.h
 #include FLAC/assert.h
 #include FLAC/metadata.h // for ::FLAC__metadata_object_is_equal()
 #include FLAC++/decoder.h
 #include share/grabbag.h
+#include share/compat.h
 extern C {
 #include test_libs_common/file_utils_flac.h
 #include test_libs_common/metadata_utils.h
diff --git a/src/test_libFLAC++/metadata_manip.cpp 
b/src/test_libFLAC++/metadata_manip.cpp
index 4ee4281..9bf0eb2 100644
--- a/src/test_libFLAC++/metadata_manip.cpp
+++ b/src/test_libFLAC++/metadata_manip.cpp
@@ -23,23 +23,15 @@
 #include stdio.h
 #include stdlib.h /* for malloc() */
 #include string.h /* for memcpy()/memset() */
-#if defined _MSC_VER || defined __MINGW32__
-#include sys/utime.h /* for utime() */
-#include io.h /* for chmod() */
-#if _MSC_VER = 1600 /* @@@ [2G limit] */
-#define fseeko fseek
-#define ftello ftell
-#endif
-#else
 #include sys/types.h /* some flavors of BSD (like OS X) require this to get 
time_t */
 #include utime.h /* for utime() */
 #include unistd.h /* for chown(), unlink() */
-#endif
 #include sys/stat.h /* for stat(), maybe chmod() */
 #include FLAC/assert.h
 #include FLAC++/decoder.h
 #include FLAC++/metadata.h
 #include share/grabbag.h
+#include share/compat.h
 extern C {
 #include test_libs_common/file_utils_flac.h
 }
diff --git a/configure.ac b/configure.ac
index 36ac6c6..c0ed842 100644
--- a/configure.ac
+++ b/configure.ac
@@ -103,11 +103,16 @@ esac
 AC_SUBST(OBJ_FORMAT)
 
 case $host in
-   *-*-cygwin|*mingw*)
+   *-*-cygwin*)
+# define this variable for enabling strict exports with 
libtool; for now, it's only supported by Win32
+LT_NO_UNDEFINED=-no-undefined
+   MINGW_WINSOCK_LIBS=
+   ;;
+   *-*-mingw*)
# define this variable for enabling strict exports with 
libtool; for now, it's only supported by Win32
LT_NO_UNDEFINED=-no-undefined
-   # -lwsock32 only needed because of ntohl() usage, can get rid 
of after that's gone:
-   MINGW_WINSOCK_LIBS=-lwsock32
+   # -lws2_32 only needed because of ntohl() usage, can get rid of 
after that's gone:
+   MINGW_WINSOCK_LIBS=-lws2_32
;;
*)
LT_NO_UNDEFINED=


signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Moving CPP hackery

[JonY]

On 2/4/2012 17:45, Erik de Castro Lopo wrote:
 JonY wrote:
 
 Looks like there are some missed defines in the test_libFLAC++. Attached
 patch fixes that.
 
 Good one. Thanks.
 
 Also, wsock32 usage is deprecated, on Win7, wsock32 forwards everything
 to ws2_32, suggest changing to -lwsock32 to -lws2_32 in configure.ac.
 Additionally, using -lwsock32 on Cygwin is wrong. Fix in config.txt.
 
 For that I think I'd prefer to purge all use of ntohl. Will make that
 a high priority.
 
 Erik

Does AC_C_BIGENDIAN work well? I assume if a system is not big endian,
its small endian. Are mid endian systems still around?



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH 2/2] OS/2 EMX natively uses AOUT so pass -f aout to NASM

[JonY]

On 2/5/2012 13:30, Erik de Castro Lopo wrote:
 Dave Yeo wrote:
 
 ---
  configure.ac |1 +
 
 Both applied (first with a minor tweak). Thanks.
 
 Erik

Unfortunately, this steps on my patch. Updated patch attached. Cygwin
really shouldn't be calling win32 API.

On the otherhand, I can't seem to find any ntohl use(???).
diff --git a/configure.ac b/configure.ac
index 04277e1..10c4669 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,10 +105,18 @@ esac
 AC_SUBST(OBJ_FORMAT)
 
 case $host in
-   *-*-cygwin|*mingw*|*emx*)
+   *emx*)
# define this variable for enabling strict exports with 
libtool; for now, it's supported by Win32 and OS/2
LT_NO_UNDEFINED=-no-undefined
;;
+   *-*-cygwin*)
+LT_NO_UNDEFINED=-no-undefined
+   ;;
+   *-*-mingw*)
+   LT_NO_UNDEFINED=-no-undefined
+   # -lws2_32 only needed because of ntohl() usage, can get rid of 
after that's gone:
+   MINGW_WINSOCK_LIBS=-lws2_32
+   ;;
*)
LT_NO_UNDEFINED=
;;


signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 2/3/2012 06:33, JonY wrote:
 On 2/3/2012 02:50, Erik de Castro Lopo wrote:
 JonY wrote:

 Attached patch builds without any warnings for MinGW.

 Sorry JonY, that patch does not apply against current git master
 which is here:

 https://git.xiph.org/?p=flac.git;a=summary

 Specifically I pulled out much of the #ifdef _MSC_VER printf stuff
 in this commit:

 
 https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797

 For example (damn thats a horrible URL):

 
 https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b

 Since your patch seems pretty similar to what I have already commited,
 I wouldn't be surprised it what we have now doesn't just compile correctly
 under MinGW.
 
 OK, will redo patch later today. My git repo still pointed to the old
 /mirrors/flac.git link, so I didn't get any updates.
 
 

OK, rebuilt with latest master, no more printf warnings. Here's another
attached patch to suppress redefinition warnings with mingw-w64 lfs64
support.
diff --git a/src/flac/decode.c b/src/flac/decode.c
index 05d86f3..2173669 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -29,10 +29,14 @@
 #if defined _MSC_VER || defined __MINGW32__
 #include sys/types.h /* for off_t */
 #if _MSC_VER = 1600 /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include errno.h
 #include math.h /* for floor() */
 #include stdio.h /* for FILE etc. */
diff --git a/src/flac/encode.c b/src/flac/encode.c
index dafa105..87ef2ef 100644
--- a/src/flac/encode.c
+++ b/src/flac/encode.c
@@ -29,10 +29,14 @@
 #if defined _MSC_VER || defined __MINGW32__
 #include sys/types.h /* for off_t */
 #if _MSC_VER = 1600 /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include errno.h
 #include limits.h /* for LONG_MAX */
 #include math.h /* for floor() */
diff --git a/src/flac/foreign_metadata.c b/src/flac/foreign_metadata.c
index 7e273a5..d4fb7c2 100644
--- a/src/flac/foreign_metadata.c
+++ b/src/flac/foreign_metadata.c
@@ -23,10 +23,14 @@
 #if defined _MSC_VER || defined __MINGW32__
 #include sys/types.h /* for off_t */
 #if _MSC_VER = 1600 /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include stdio.h /* for FILE etc. */
 #include stdlib.h /* for calloc() etc. */
 #include string.h /* for memcmp() etc. */
diff --git a/src/flac/iffscan.c b/src/flac/iffscan.c
index da74a5f..2cb9075 100644
--- a/src/flac/iffscan.c
+++ b/src/flac/iffscan.c
@@ -26,10 +26,14 @@
 #if defined _MSC_VER || defined __MINGW32__
 #include sys/types.h /* for off_t */
 #if _MSC_VER = 1600 /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include foreign_metadata.h
 
 static FLAC__uint32 unpack32be_(const FLAC__byte *b)
diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c
index ac6473e..9ef9882 100644
--- a/src/libFLAC/metadata_iterators.c
+++ b/src/libFLAC/metadata_iterators.c
@@ -47,9 +47,13 @@
 #include io.h /* for chmod() */
 #include sys/types.h /* for off_t */
 #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
+#endif
 #else
 #include sys/types.h /* some flavors of BSD (like OS X) require this to get 
time_t */
 #include utime.h /* for utime() */
diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
index 72d9e43..0323d73 100644
--- a/src/libFLAC/stream_decoder.c
+++ b/src/libFLAC/stream_decoder.c
@@ -48,10 +48,14 @@
 #include sys/types.h /* for off_t */
 #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
 #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include FLAC/assert.h
 #include share/alloc.h
 #include protected/stream_decoder.h
diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c
index 8fb3209..0b6d8c2 100644
--- a/src/libFLAC/stream_encoder.c
+++ b/src/libFLAC/stream_encoder.c
@@ -48,10 +48,14 @@
 #include sys/types.h /* for off_t */
 #if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
 #if _MSC_VER = 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
+#ifndef fseeko
 #define fseeko fseek
+#endif
+#ifndef ftello
 #define ftello ftell
 #endif
 #endif
+#endif
 #include FLAC/assert.h
 #include FLAC/stream_decoder.h
 #include share/alloc.h
diff --git a/src/test_libFLAC/decoders.c b/src/test_libFLAC/decoders.c
index e45e722..70127cf 100644
--- a/src/test_libFLAC/decoders.c

Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 2/1/2012 22:36, JonY wrote:
 On 2/1/2012 18:52, Erik de Castro Lopo wrote:
 JonY wrote:

 Alright, here's a quick fix, although it is more ugly than I remembered.

 Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
 where available, and falls back to I64 on MSVC and then ll for others,
 all format warnings suppressed.

 JonY,

 Sorry for the delay on actually getting on to this.

 I tried your patch, but it wasn't quite right. The problem is that %ll
 is the correct format specifier for uint64_t on 32bit Linux but not
 on 64 bit Linux.

 
 Something is very very wrong about the above statements. I thought I
 used PRI?64 when inttypes.h is found (Linux should have it, old code
 uses %ll? anyway for non-msvc, so shouldn't have any new issues).
 
 inttypes.h and stdint.h is supposed to be abstractions to remove these
 issues.
 
 In C99, the correct way to print a uint64_t value is:

  printf (THe value is :  PRIu64 \n, value) ;

 I have gone ahead and fixed this through the code and fixed this, but I
 may have broken some either MSVC or MinGW on the way. I'd appreciate it
 if you test whats in git now.

 For those files where any compiler baulks at the PRIu64/PRIx64/PRId64,
 you should add a #ifdef block that might look something like:

 #ifdef HAVE_INTTYPES_H
 #include inttypes.h
 #else
 #if defined (_MSC_VER)  ! defined (PRId64)
 #define PRId64 I64d
 #endif
 #if defined (_MSC_VER)  ! defined (PRIu64)
 #define PRIu64 I64u
 #endif
 #endif

 We'll worry about compilers that don't have the PRI_64 values as we find
 them.

 
 OK, I'll do a quick test build tomorrow. More thorough testing will come
 during the weekends.
 

Attached patch builds without any warnings for MinGW.

diff --git a/examples/c/decode/file/main.c b/examples/c/decode/file/main.c
index 32b5559..67028bb 100644
--- a/examples/c/decode/file/main.c
+++ b/examples/c/decode/file/main.c
@@ -31,6 +31,7 @@
 #include stdio.h
 #include stdlib.h
 #include FLAC/stream_decoder.h
+#include FLAC/compat.h
 
 static FLAC__StreamDecoderWriteStatus write_callback(const FLAC__StreamDecoder 
*decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void 
*client_data);
 static void metadata_callback(const FLAC__StreamDecoder *decoder, const 
FLAC__StreamMetadata *metadata, void *client_data);
@@ -174,11 +175,7 @@ void metadata_callback(const FLAC__StreamDecoder *decoder, 
const FLAC__StreamMet
fprintf(stderr, sample rate: %u Hz\n, sample_rate);
fprintf(stderr, channels   : %u\n, channels);
fprintf(stderr, bits per sample: %u\n, bps);
-#ifdef _MSC_VER
-   fprintf(stderr, total samples  : %I64u\n, total_samples);
-#else
-   fprintf(stderr, total samples  : %llu\n, total_samples);
-#endif
+   fprintf(stderr, total samples  : %PRIu64\n, total_samples);
}
 }
 
diff --git a/examples/c/encode/file/main.c b/examples/c/encode/file/main.c
index 0f7f4c0..9be55b0 100644
--- a/examples/c/encode/file/main.c
+++ b/examples/c/encode/file/main.c
@@ -33,6 +33,7 @@
 #include string.h
 #include FLAC/metadata.h
 #include FLAC/stream_encoder.h
+#include FLAC/compat.h
 
 static void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64 
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned 
total_frames_estimate, void *client_data);
 
@@ -164,10 +165,5 @@ int main(int argc, char *argv[])
 void progress_callback(const FLAC__StreamEncoder *encoder, FLAC__uint64 
bytes_written, FLAC__uint64 samples_written, unsigned frames_written, unsigned 
total_frames_estimate, void *client_data)
 {
(void)encoder, (void)client_data;
-
-#ifdef _MSC_VER
-   fprintf(stderr, wrote %I64u bytes, %I64u/%u samples, %u/%u frames\n, 
bytes_written, samples_written, total_samples, frames_written, 
total_frames_estimate);
-#else
-   fprintf(stderr, wrote %llu bytes, %llu/%u samples, %u/%u frames\n, 
bytes_written, samples_written, total_samples, frames_written, 
total_frames_estimate);
-#endif
+   fprintf(stderr, wrote %PRIu64 bytes, %PRIu64/%u samples, %u/%u 
frames\n, bytes_written, samples_written, total_samples, frames_written, 
total_frames_estimate);
 }
diff --git a/include/FLAC/compat.h b/include/FLAC/compat.h
new file mode 100755
index 000..831d882
--- /dev/null
+++ b/include/FLAC/compat.h
@@ -0,0 +1,57 @@
+/* libFLAC - Free Lossless Audio Codec library
+ * Copyright (C) 2001,2002,2003,2004,2005,2006,2007,2008,2009  Josh Coalson
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer

Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 2/1/2012 18:52, Erik de Castro Lopo wrote:
 JonY wrote:
 
 Alright, here's a quick fix, although it is more ugly than I remembered.

 Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
 where available, and falls back to I64 on MSVC and then ll for others,
 all format warnings suppressed.
 
 JonY,
 
 Sorry for the delay on actually getting on to this.
 
 I tried your patch, but it wasn't quite right. The problem is that %ll
 is the correct format specifier for uint64_t on 32bit Linux but not
 on 64 bit Linux.
 

Something is very very wrong about the above statements. I thought I
used PRI?64 when inttypes.h is found (Linux should have it, old code
uses %ll? anyway for non-msvc, so shouldn't have any new issues).

inttypes.h and stdint.h is supposed to be abstractions to remove these
issues.

 In C99, the correct way to print a uint64_t value is:
 
  printf (THe value is :  PRIu64 \n, value) ;
 
 I have gone ahead and fixed this through the code and fixed this, but I
 may have broken some either MSVC or MinGW on the way. I'd appreciate it
 if you test whats in git now.
 
 For those files where any compiler baulks at the PRIu64/PRIx64/PRId64,
 you should add a #ifdef block that might look something like:
 
 #ifdef HAVE_INTTYPES_H
 #include inttypes.h
 #else
 #if defined (_MSC_VER)  ! defined (PRId64)
 #define PRId64 I64d
 #endif
 #if defined (_MSC_VER)  ! defined (PRIu64)
 #define PRIu64 I64u
 #endif
 #endif
 
 We'll worry about compilers that don't have the PRI_64 values as we find
 them.
 

OK, I'll do a quick test build tomorrow. More thorough testing will come
during the weekends.



signature.asc
Description: OpenPGP digital signature
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 11/16/2011 06:49, JonY wrote:
 On 11/16/2011 03:20, Erik de Castro Lopo wrote:
 JonY wrote:

 On 11/14/2011 18:01, JonY wrote:
 On 11/10/2011 19:22, JonY wrote:
 On 11/10/2011 18:39, Erik de Castro Lopo wrote:

 I'm subscribed to the list (and I set my reply-to to the list).
 Please do not CC me.

 JonY wrote:

 Its probably on one of the sf tracker somewhere, I can't seem to find it
 anymore. It wasn't anything complicated, so I should be able to redo it
 quickly.

 I'm a Linux guy. I do not have easy access to a windows machine
 and don't have the time or patience to maintain one.

 For windows stuff I'll be relying on others to provide and test
 patches.

 Erik

 Alright, here's a quick fix, although it is more ugly than I remembered.

 Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
 where available, and falls back to I64 on MSVC and then ll for others,
 all format warnings suppressed.

 Tested on MinGW.

 Sven-Hendrik, or any other mingw guys around, do you mind testing the
 patch too? Patch based on git master from
 https://git.xiph.org/mirrors/flac.git.


 Ifdef changes now consolidated into a single file.

 Ping, no comments?

 I noticed some more ifdeferies around that needs consolidating and
 warnings that need suppressing, that can go into a separate patch.

 Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying
 to make my machine usable.

 Erik
 
 Wow ok, haven't touched it since the gnone2 days, it was pretty decent
 back then.
 
 I'll come back later then.
 

Ping, anything new?





signature.asc
Description: OpenPGP digital signature
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 11/14/2011 18:01, JonY wrote:
 On 11/10/2011 19:22, JonY wrote:
 On 11/10/2011 18:39, Erik de Castro Lopo wrote:

 I'm subscribed to the list (and I set my reply-to to the list).
 Please do not CC me.

 JonY wrote:

 Its probably on one of the sf tracker somewhere, I can't seem to find it
 anymore. It wasn't anything complicated, so I should be able to redo it
 quickly.

 I'm a Linux guy. I do not have easy access to a windows machine
 and don't have the time or patience to maintain one.

 For windows stuff I'll be relying on others to provide and test
 patches.

 Erik

 Alright, here's a quick fix, although it is more ugly than I remembered.

 Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
 where available, and falls back to I64 on MSVC and then ll for others,
 all format warnings suppressed.

 Tested on MinGW.

 Sven-Hendrik, or any other mingw guys around, do you mind testing the
 patch too? Patch based on git master from
 https://git.xiph.org/mirrors/flac.git.

 
 Ifdef changes now consolidated into a single file.

Ping, no comments?

I noticed some more ifdeferies around that needs consolidating and
warnings that need suppressing, that can go into a separate patch.



signature.asc
Description: OpenPGP digital signature
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 11/16/2011 03:20, Erik de Castro Lopo wrote:
 JonY wrote:
 
 On 11/14/2011 18:01, JonY wrote:
 On 11/10/2011 19:22, JonY wrote:
 On 11/10/2011 18:39, Erik de Castro Lopo wrote:

 I'm subscribed to the list (and I set my reply-to to the list).
 Please do not CC me.

 JonY wrote:

 Its probably on one of the sf tracker somewhere, I can't seem to find it
 anymore. It wasn't anything complicated, so I should be able to redo it
 quickly.

 I'm a Linux guy. I do not have easy access to a windows machine
 and don't have the time or patience to maintain one.

 For windows stuff I'll be relying on others to provide and test
 patches.

 Erik

 Alright, here's a quick fix, although it is more ugly than I remembered.

 Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
 where available, and falls back to I64 on MSVC and then ll for others,
 all format warnings suppressed.

 Tested on MinGW.

 Sven-Hendrik, or any other mingw guys around, do you mind testing the
 patch too? Patch based on git master from
 https://git.xiph.org/mirrors/flac.git.


 Ifdef changes now consolidated into a single file.

 Ping, no comments?

 I noticed some more ifdeferies around that needs consolidating and
 warnings that need suppressing, that can go into a separate patch.
 
 Sorry, I got hit by the Gnome3 catastrophe of 2011 and I'm still trying
 to make my machine usable.
 
 Erik

Wow ok, haven't touched it since the gnone2 days, it was pretty decent
back then.

I'll come back later then.




signature.asc
Description: OpenPGP digital signature
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 11/10/2011 08:02, Erik de Castro Lopo wrote:
 JonY wrote:
 
 I submitted a patch sometime ago to correct printf specifiers for win32
 by using inttypes.h, but there were no response, so I thought flac
 development was dead.
 
 Development is probably complete. Maintenance should continue.
 
 Not sure where the patch went or if its still valid.
 
 If you sent it to this list, the mailing list archive should be here:
 
 http://lists.xiph.org/mailman/listinfo/flac-dev
 

Its probably on one of the sf tracker somewhere, I can't seem to find it
anymore. It wasn't anything complicated, so I should be able to redo it
quickly.





signature.asc
Description: OpenPGP digital signature
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

[JonY]

On 11/10/2011 06:58, Erik de Castro Lopo wrote:
 Sven-Hendrik Haase wrote:
 
 Si señor: http://code.entropywave.com/git/flac.git
 
 Ok, there are about 6 commits there. Over the weekend I'll
 have a look at them and if they're fine, I'll push them to
 the Xiph Git repo.
 
 If anyone else has Flac patches that they would like to
 see commited to the Xiph Git repo, now would be a good time
 to speak up.
 
 Cheers,
 Erik

I submitted a patch sometime ago to correct printf specifiers for win32
by using inttypes.h, but there were no response, so I thought flac
development was dead.

Not sure where the patch went or if its still valid.



signature.asc
Description: OpenPGP digital signature
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev