search for: windows_unicode_filenam

Erik de Castro Lopo wrote: > When I tried apply that patch, all but one hunk succeeded. I inspected > the rejected part, but that seemed to have already been applied. '1_sources.patch' creates windows_unicode_filenames.h and windows_unicode_filenames.c files that don't exist in the current git. > Lets just get a patch that fixes what we have now. Here it is: the missing parts of d40a6bc commit are in the attached fix_d40a6bc_commit.patch Also an (optional) use_winapi_macro.patch from <http://lis...

This patch renames flac_internal_CreateFile_utf8() function to grabbag__CreateFile_utf8() and moves it from /src/libFLAC/windows_unicode_filenames.c into src/share/grabbag/file.c This function is not used by libFLAC anyway. After this, it should be possible to compile libFLAC as UWP. In the old code there were 3 different #if conditionals around the code that uses CreateFile_utf8(): 1) #ifdef _WIN32 ... #endif 2) #if defined _WIN32 &am...

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The set of four patches that remove dependency of libFLAC on win_utf8_io. >> >> Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and makefile.lite) >> >> Please review, especially makefile patches, I'm not very familiar with them. > > Applied. All good. Thanks. But the 1st patch

...to <http://stackoverflow.com/questions/9509166/what-is-winapifamily-h> winapifamily.h is only available since MSVS 2012, so build will fail in older versions of Visual Studio (and in some older versions of MinGW). > #include "share/win_utf8_io.h" > #include "share/windows_unicode_filenames.h" > @@ -164,11 +165,13 @@ size_t strlen_utf8(const char *str) > int win_get_console_width(void) > { > int width = 80; > +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) Apparently these preprocessor defines are from winapifamily.h so it won't work in older MSVS...

...ree today, after many successful compilations over the last few weeks, a new error is appearing before compilation bails out. This is a cross-compilation using gcc-5.3.0 running on GNU/Linux, with the objects being built for a mingw-w64-x86_64 host. Among other things, the compiler is looking for windows_unicode_filenames.h but it isn't there. Also, I'm not a programmer, and am not sure where the #define for HANDLE should be found. Anyway, I hope this error report may be of some help to you. libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./include -I../../include -DNDEBUG...

...attending to code relevant to this error > in the recent past. It seems that some patch was partially applied. Two possible fixes for the problem are attached. The first adds missing defines to src/flac/decode.c and src/share/grabbag/file.c The second removes #ifdef...#endif directives from windows_unicode_filenames.(c|h) (they're mutually exclusive - there's no point in applying both of them) -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_variant1.patch Type: application/octet-stream Size: 745 bytes Desc: not available Url : http://lists.xiph.org/pipermail/f...

Thank you for the feedback. This is cross-compiling for mingw-w64-x86_64 using gcc-5.3.0 and mingw-w64-4.0.4 on GNU/Linux. Upon attempting to compile now, a large number of errors occur in flac/decode.c which I have placed at the end of this email. They are eased by adding this to decode.c: #if _WIN32 #include <windows.h> #include <shlobj.h> #endif ...among the headers. Then, this

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple