Hi all,
The latest pre-release is here:
http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz
but there will probably need to be at least one more.
I've tested this on
x86_64-linux
powerpc-linux
i386-openbsd5.2
i386-freebsd9
The majority of changes since the last pre-release is the addition of
Janne Hyv?rinen's utf8 I/O functionality. Janne's original patch was
MSVC only. I hacked it to work with MinGW as well (including cross
compiling from Linux).
I need people to test this with MSVC (I may have broken something)
and with MinGW (I can cross-compile but I can't run the tests).
Please report back successes and failures (hopefully with patches).
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
I'm worried about some of the modifications done to the UTF-8 patch. In commit 2199d086921eb37d249cae0731f334556ec6209d #ifdef checks were changed from specific FLAC__STRINGS_IN_UTF8 to generic _WIN32 and the specific defines were later removed in commit 0cd2e9ed6918b782195d0024dd19dcfa39df8f82. The reason I had them this way is that FLAC API has public functions that work with filenames. Default compile options for FLAC would be unaffected and existing programs that rely on ANSI filenames would continue to work. The new configuration option "Release (UTF-8)" was meant to isolate the changes so that only official bundled frontends that know about the changes would use them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 14:40, Erik de Castro Lopo wrote:> Hi all, > > The latest pre-release is here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz >flac-1.3.0pre3/include/share/compat.h:146:31: fatal error: share/win_utf8_io.h: No such file or directory -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWXz5AAoJEOs4Jb6SI2CwgDIH/AyvtKG+bK2GTTQ4vbbN6+NT JC4nXhbxsMJU0hVI8KkAGfY5CkprHDf9kDGnb33rPn0/PDAYmeMYFiK99IfjI2ac qQ8fG8VBsubOeRQUgwKhwnzKjAx4+LSXcCa4PsM2DYdNSlCsYMPmgvChq5QAVm3L pd3/2Xa/XRJD7nOox4NIhLf+Pod661zVaK8NV39BEn1vkrCUbn5EHCWRZAz4sOxP XlFKDUiSNqmZ2xr2JOU1C8dJVQH+C8v0NBLmhBiRe9QPs2E+DRkyVlQ1cL7fTzfL sqwOtt1A8G3+RB4PmOZ50nQnclUzVMVbXA3pAsP8qeyZLEd5guM5dKGpWtKlQC0=OkGt -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 16:24, Janne Hyv?rinen wrote:> I'm worried about some of the modifications done to the UTF-8 > patch. In commit 2199d086921eb37d249cae0731f334556ec6209d #ifdef > checks were changed from specific FLAC__STRINGS_IN_UTF8 to generic > _WIN32 and the specific defines were later removed in commit > 0cd2e9ed6918b782195d0024dd19dcfa39df8f82. > > The reason I had them this way is that FLAC API has public > functions that work with filenames. Default compile options for > FLAC would be unaffected and existing programs that rely on ANSI > filenames would continue to work. The new configuration option > "Release (UTF-8)" was meant to isolate the changes so that only > official bundled frontends that know about the changes would use > them.That's a valid point. Alternative approach (something i saw in libxml2 recently) is to make UTF-8-to-UTF-16 conversion a bit smarter: First try the conversion, assuming the string to be UTF-8-encoded. If that fails, assume the string is in native encoding, and run the conversion function again with appropriate source codepage (when using W32 conversion functions that would be CP_ACP). If that fails, fail the function call as usual. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWX2+AAoJEOs4Jb6SI2Cw914IAMkkQr7ZmiZ/Ei9nhXEtKATe oASC/VEv/1MqJK2u1VF0hDIMjVjqHbqX2I+twEMQR5UXmH1oJXmhbZjS5s9J2Iqq l8F9MRp9AhCpHo0+zqWQ3He0YmdYnSWLO3L6LLph9oGexDIBke8y2K4n7Vi+tNgP nVpe6+O/gXws/JLpPpfUSvHv9Nzl/yDPBlBc2FVsTYs0dWGInP1RD1ugitohGgcH VHzwit3+BmZW7NZer4fBhzIaOoqmDhLrwj3QFLfnosaj0H73U+Hiav5rF6vhKPq5 RNpsvbJsAZXanmpDteZmgXjA5ll7oEfe+IDLubm+0c+XXAYgtVz5njiLKcYd4+Y=/Ad4 -----END PGP SIGNATURE-----
Zip with random patches: flac_mac: fixes some missing parameters from safe string handling changes in flac_mac's main.c flac_mac_project: adds flac's include dir for the project so new functions can be found progress_display: flac testing progress display used old functions that didn't get utf-8 decoding msvc_flac_version: changes versions number from 1.3.0pre2 to 1.3.0pre3 compat_h_msvc_fix: fixes compiling on MSVC -------------- next part -------------- A non-text attachment was scrubbed... Name: flac_patches.zip Type: application/x-zip-compressed Size: 2883 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130401/623d6492/attachment.bin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 16:55, Janne Hyv?rinen wrote:> > On 1.4.2013 15:29, LRN wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 01.04.2013 16:24, Janne Hyv?rinen wrote: >>> I'm worried about some of the modifications done to the UTF-8 >>> patch. In commit 2199d086921eb37d249cae0731f334556ec6209d >>> #ifdef checks were changed from specific FLAC__STRINGS_IN_UTF8 >>> to generic _WIN32 and the specific defines were later removed >>> in commit 0cd2e9ed6918b782195d0024dd19dcfa39df8f82. >>> >>> The reason I had them this way is that FLAC API has public >>> functions that work with filenames. Default compile options >>> for FLAC would be unaffected and existing programs that rely on >>> ANSI filenames would continue to work. The new configuration >>> option "Release (UTF-8)" was meant to isolate the changes so >>> that only official bundled frontends that know about the >>> changes would use them. >> That's a valid point. >> >> Alternative approach (something i saw in libxml2 recently) is to >> make UTF-8-to-UTF-16 conversion a bit smarter: First try the >> conversion, assuming the string to be UTF-8-encoded. If that >> fails, assume the string is in native encoding, and run the >> conversion function again with appropriate source codepage (when >> using W32 conversion functions that would be CP_ACP). If that >> fails, fail the function call as usual. >> > > I initially had it that way. I just didn't feel comfortable leaving > it as it could in theory access wrong files. Granted, it would > require having some rather weird names for files but it's still a > possibility. >Another option is to have a flag in the library, which can be changed at runtime (by calling a special library function, say, "flac_set_utf_mode()"). If that flag is set, assume strings to be in UTF-8. Otherwise assume them to be in local codepage. You can still have 2 different builds (UTF-8 one and normal one), they will just use different default values for that flag. Official frontends will know to call flac_set_utf_mode(), and will be able to work with UTF-8 version regardless of the build. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWYXZAAoJEOs4Jb6SI2CwAKoIALJRAGB0VE7/nRNBkE9OCQbC tBxiBZVSOSHQ7E03/jaWfmeImM3FyBoj5UhvWPlsX7YvBIOaF6YvhYf2oZews0VZ DUcX3Vdfg7xAU5ZFkAl4sFEN6YMT5oBYENxZ7UgeMv8COe7f3gN9mJ3ril/OYclw 7HDItgrwaramtBjLnF9lMAmKXi+Vv+nI12+bGrTOYNN7kIpPBten9QdVywcaIw+z uRpEJeqxQ05QIDRhs+QlB+BnZJkiXi3kdLlWgZ7TiIyvi+Ll5tpczXIrdc1ZM3Fk K5aZmmyTyZdonGtqN+Ggq6UNFEaOBqseCYPEFRY+UoUojUCSnvuH7I5FiJwbae0=jcbY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 16:26, LRN wrote:> On 01.04.2013 14:40, Erik de Castro Lopo wrote: >> Hi all, > >> The latest pre-release is here: > >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz > >> > flac-1.3.0pre3/include/share/compat.h:146:31: fatal error: > share/win_utf8_io.h: No such file or directory >OK, i downloaded that one from git, now i get a different problem: flac-1.3.0pre3/include/share/win_utf8_io.h:23:43: warning: 'struct _stat64' declared inside parameter list [enabled by default] flac-1.3.0pre3/include/share/win_utf8_io.h:23:43: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] flac-1.3.0pre3/src/share/grabbag/file.c: In function 'grabbag__file_copy_metadata': flac-1.3.0pre3/src/share/grabbag/file.c:53:21: error: storage size of 'srcstat' isn't known AFAIU, mingw.org headers don't have _stat64 struct at all, they have __stat64 instead. _stat64 is from mingw-w64 headers (mingw-w64 has a #define __stat64 _stat64, so using __stat64 should work). You also need to define __MSVCRT_VERSION__=0x0601, because that is the condition on which mingw.org will define __stat64 structure and _stat64() function. Here are the patches. With these flac should compile with both mingw.org and mingw-w64 (tried both). I didn't run the testsuite though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRWYkDAAoJEOs4Jb6SI2CwDL4H/1fKxEvO0Pd6X6FAGQPlKN+l UMoWNSAD+IaVzJ7G5j6Guh8LZPn56FuFLC83JeQfn88fdQu4qmQC3sxofJ2juxmM QIcqzyX6cxSIAkWnorAXNCBHN+nozC0WOU1LvY10DDLIyF/Wgslq7gklJmxRrSlh Aq5vrtMWJ6ClElgD8J3D75SJ626BLs2yYuTlbhBayOm6CdmQIl62IIQG1n4T52z5 8kxZxKdzQYjbZvYHKsdvrYXZv0mLk0WMgNgODbBN8U6sxwGKtWi7p3JmtUpfO9Ln oo727weN8kBW0jzg2RcsyZpvRbbQ4ww/58aR/X/1gW3t2dd4B0Kidg4HJB192pE=YcvV -----END PGP SIGNATURE----- -------------- next part -------------- --- flac-1.3.0pre3/configure.ac.orig 2013-04-01 17:09:45 +0400 +++ flac-1.3.0pre3/configure.ac 2013-04-01 17:10:21 +0400 @@ -129,6 +129,7 @@ *-*-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" + CPPFLAGS="-D__MSVCRT_VERSION__=0x0601 $CPPFLAGS" os_is_windows=yes ;; *) -------------- next part -------------- --- flac-1.3.0pre3/include/share/compat.h.orig 2013-04-01 16:24:18 +0400 +++ flac-1.3.0pre3/include/share/compat.h 2013-04-01 16:38:23 +0400 @@ -175,7 +175,7 @@ #endif #ifdef _WIN32 -#define flac_stat_s _stat64 /* stat struct */ +#define flac_stat_s __stat64 /* stat struct */ #define flac_fstat _fstat64 #else #define flac_stat_s stat /* stat struct */ --- flac-1.3.0pre3/include/share/win_utf8_io.h.orig 2013-04-01 16:32:02 +0400 +++ flac-1.3.0pre3/include/share/win_utf8_io.h 2013-04-01 16:39:09 +0400 @@ -20,7 +20,7 @@ FILE *fopen_utf8(const char *filename, const char *mode); int stat_utf8(const char *path, struct stat *buffer); -int _stat64_utf8(const char *path, struct _stat64 *buffer); +int _stat64_utf8(const char *path, struct __stat64 *buffer); int chmod_utf8(const char *filename, int pmode); int utime_utf8(const char *filename, struct utimbuf *times); int unlink_utf8(const char *filename); --- flac-1.3.0pre3/src/share/win_utf8_io/win_utf8_io.c.orig 2013-04-01 16:24:18 +0400 +++ flac-1.3.0pre3/src/share/win_utf8_io/win_utf8_io.c 2013-04-01 16:39:34 +0400 @@ -182,7 +182,7 @@ return f; } -int _stat64_utf8(const char *path, struct _stat64 *buffer) +int _stat64_utf8(const char *path, struct __stat64 *buffer) { wchar_t *wpath; int ret;
LRN wrote:> flac-1.3.0pre3/include/share/compat.h:146:31: fatal error: > share/win_utf8_io.h: No such file or directoryAdd that to EXTRA_DIST in include/share/Makefile.am. Thanks. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Janne Hyv?rinen wrote:> Zip with random patches: > > flac_mac: fixes some missing parameters from safe string handling > changes in flac_mac's main.c > flac_mac_project: adds flac's include dir for the project so new > functions can be found > progress_display: flac testing progress display used old functions that > didn't get utf-8 decoding > msvc_flac_version: changes versions number from 1.3.0pre2 to 1.3.0pre3 > compat_h_msvc_fix: fixes compiling on MSVCApplied, thanks! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 1.4.2013 13:40, Erik de Castro Lopo wrote:> I need people to test this with MSVC (I may have broken something) > and with MinGW (I can cross-compile but I can't run the tests). > > Please report back successes and failures (hopefully with patches). > > Cheers, > ErikI ran the testset with my 32-bit MSYS compile (I use MSYS build from http://xhmikosr.1f0.de/tools/). All tests passed. I noticed a typo in a warning text while running them though, here's a patch for that. -------------- next part -------------- diff --git a/src/metaflac/options.c b/src/metaflac/options.c index 6aded4a..e8e6151 100644 --- a/src/metaflac/options.c +++ b/src/metaflac/options.c @@ -1084,5 +1084,5 @@ FLAC__bool parse_application_data_format(const char *in, FLAC__bool *out) void undocumented_warning(const char *opt) { - flac_fprintf(stderr, "WARNING: undocmented option --%s should be used with caution,\n only for repairing a damaged STREAMINFO block\n", opt); + flac_fprintf(stderr, "WARNING: undocumented option --%s should be used with caution,\n only for repairing a damaged STREAMINFO block\n", opt); }
Janne Hyv?rinen wrote:> I ran the testset with my 32-bit MSYS compile (I use MSYS build from > http://xhmikosr.1f0.de/tools/). All tests passed. > I noticed a typo in a warning text while running them though, here's a > patch for that.Applied. thanks. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 01-04-13 12:40, Erik de Castro Lopo wrote:> I've tested this on > > x86_64-linux > powerpc-linux > i386-openbsd5.2 > i386-freebsd9I've tested this on x86_64-linux as well, but still no static building possible (see earlier post on this). Someone over at HydrogenAudio has successfully built statically linked, but gets all weird kinds of errors in the resulting binary (http://www.hydrogenaudio.org/forums/index.php?s=ea13ae7a727c13c54a98c9230a7cbc67&showtopic=99757&view=findpost&p=830074) I've built it on "armv6l-unknown-linux-gnueabihf" (which is Raspbian) as well, all tests passed, but I get a few warnings that don't show up on my amd64 build. I've included them below, I don't know what they mean exactly, but probably someone knows what to do with this? These show up with both plain ./configure as well as with --enable-static> CC grabbag/cuesheet.lo > grabbag/cuesheet.c: In function 'grabbag__cuesheet_emit': > grabbag/cuesheet.c:645:47: warning: declaration of 'index' shadows a > global declaration [-Wshadow] > [...] > CC > replaygain_synthesis/replaygain_synthesis_libreplaygain_synthesis_la-replaygain_synthesis.lo > replaygain_synthesis/replaygain_synthesis.c: In function > 'FLAC__replaygain_synthesis__init_dither_context': > replaygain_synthesis/replaygain_synthesis.c:212:6: warning: > declaration of 'index' shadows a global declaration [-Wshadow] > [...] > CC md5.lo > md5.c: In function 'format_input_': > md5.c:282:25: warning: cast increases required alignment of target > type [-Wcast-align] > md5.c:288:24: warning: cast increases required alignment of target > type [-Wcast-align] > CC memory.lo > CC metadata_iterators.lo > metadata_iterators.c: In function > 'write_metadata_block_data_cuesheet_cb_': > metadata_iterators.c:2714:41: warning: declaration of 'index' shadows > a global declaration [-Wshadow] > CC metadata_object.lo > metadata_object.c: In function > 'FLAC__metadata_object_vorbiscomment_replace_comment': > metadata_object.c:1275:13: warning: declaration of 'index' shadows a > global declaration [-Wshadow] > metadata_object.c: In function > 'FLAC__metadata_object_cuesheet_track_insert_index': > metadata_object.c:1516:177: warning: declaration of 'index' shadows a > global declaration [-Wshadow] > metadata_object.c: In function > 'FLAC__metadata_object_cuesheet_track_insert_blank_index': > metadata_object.c:1540:38: warning: declaration of 'index' shadows a > global declaration [-Wshadow] > CC stream_decoder.lo > stream_decoder.c: In function 'read_metadata_cuesheet_': > stream_decoder.c:1808:43: warning: declaration of 'index' shadows a > global declaration [-Wshadow] > CC stream_encoder.lo > CC stream_encoder_framing.lo > stream_encoder_framing.c: In function 'FLAC__add_metadata_block': > stream_encoder_framing.c:164:49: warning: declaration of 'index' > shadows a global declaration [-Wshadow] > [...] > CC decode.o > decode.c: In function ?write_callback?: > decode.c:965:28: warning: cast increases required alignment of target > type [-Wcast-align] > decode.c:966:28: warning: cast increases required alignment of target > type [-Wcast-align] > decode.c:967:28: warning: cast increases required alignment of target > type [-Wcast-align] > decode.c:968:28: warning: cast increases required alignment of target > type [-Wcast-align] > CC encode.o > encode.c:118:34: warning: cast increases required alignment of target > type [-Wcast-align] > encode.c:119:33: warning: cast increases required alignment of target > type [-Wcast-align] > CC utils.o > utils.c: In function ?local__parse_cue_?: > utils.c:86:96: warning: declaration of ?index? shadows a global > declaration [-Wshadow] > utils.c: In function ?local__find_closest_cue_?: > utils.c:122:118: warning: declaration of ?index? shadows a global > declaration [-Wshadow] > [...] > CC operations.o > operations.c: In function ?write_metadata?: > operations.c:635:50: warning: declaration of ?index? shadows a global > declaration [-Wshadow] > CC operations_shorthand_cuesheet.o > operations_shorthand_cuesheet.c: In function ?import_cs_from?: > operations_shorthand_cuesheet.c:158:19: warning: declaration of > ?index? shadows a global declaration [-Wshadow] > [...] > CC metadata_object.o > metadata_object.c: In function ?vc_replace_new_?: > metadata_object.c:263:6: warning: declaration of ?index? shadows a > global declaration [-Wshadow] > metadata_object.c: In function ?tr_set_new_?: > metadata_object.c:365:124: warning: declaration of ?index? shadows a > global declaration [-Wshadow] > metadata_object.c: In function ?tr_insert_new_?: > metadata_object.c:380:127: warning: declaration of ?index? shadows a > global declaration [-Wshadow] > metadata_object.c: In function ?test_metadata_object?: > metadata_object.c:507:38: warning: declaration of ?index? shadows a > global declaration [-Wshadow] > CCLD test_libFLAC
Martijn van Beurden wrote:> I've tested this on x86_64-linux as well, but still no static building > possible (see earlier post on this). Someone over at HydrogenAudio has > successfully built statically linked, but gets all weird kinds of errors > in the resulting binary > (http://www.hydrogenaudio.org/forums/index.php?s=ea13ae7a727c13c54a98c9230a7cbc67&showtopic=99757&view=findpost&p=830074)Sigh, why are people reporting problem in the HA forums instead of here?> I've built it on "armv6l-unknown-linux-gnueabihf" (which is Raspbian) as > well, all tests passed, but I get a few warnings that don't show up on > my amd64 build. I've included them below, I don't know what they mean > exactly, but probably someone knows what to do with this? These show up > with both plain ./configure as well as with --enable-static > > > CC grabbag/cuesheet.lo > > grabbag/cuesheet.c: In function 'grabbag__cuesheet_emit': > > grabbag/cuesheet.c:645:47: warning: declaration of 'index' shadows aThats benign and something I have noted to fix in the release after the one I'm working on. Basically is a name clash between a local variable named 'index' and a function in <string.h>. Later versions of GCC don't complain about this even with -Wshadow.> > decode.c: In function ?write_callback?: > > decode.c:965:28: warning: cast increases required alignment of target > > type [-Wcast-align] > > decode.c:966:28: warning: cast increases required alignment of target > > type [-Wcast-align] > > decode.c:967:28: warning: cast increases required alignment of target > > type [-Wcast-align] > > decode.c:968:28: warning: cast increases required alignment of target > > type [-Wcast-align] > > CC encode.o > > encode.c:118:34: warning: cast increases required alignment of target > > type [-Wcast-align] > > encode.c:119:33: warning: cast increases required alignment of target > > type [-Wcast-align]Those I will defintely look at. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Hi Erik, Am 01.04.2013 um 12:40 schrieb Erik de Castro Lopo <mle+la at mega-nerd.com>:> The latest pre-release is here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz > > but there will probably need to be at least one more. > > I've tested this on > > x86_64-linux > powerpc-linux > i386-openbsd5.2 > i386-freebsd9 > > The majority of changes since the last pre-release is the addition of > Janne Hyv?rinen's utf8 I/O functionality. Janne's original patch was > MSVC only. I hacked it to work with MinGW as well (including cross > compiling from Linux). > > I need people to test this with MSVC (I may have broken something) > and with MinGW (I can cross-compile but I can't run the tests). > > Please report back successes and failures (hopefully with patches).There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors:> CC bitreader.lo > "bitreader.c", line 494: warning: implicit function declaration: MIN > CC bitwriter.lo > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern inline function > "bitwriter.c", line 277: warning: implicit function declaration: MIN > "bitwriter.c", line 316: reference to static identifier "bitwriter_grow_" in extern inline function > cc: acomp failed for bitwriter.c > gmake[4]: *** [bitwriter.lo] Error 1Either bitwriter_grow_ can be made non-static or FLAC__bitwriter_write_zeroes not inline or also static to work around this. The attached patch fixes the issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Do-not-make-functions-static-which-are-used-by-inlin.patch Type: application/octet-stream Size: 1440 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130405/70c28bfc/attachment.obj -------------- next part -------------- The implicit function MIN should according to src/libFLAC/include/private/macros.h be in sys/param.h if that header file is available. On Solaris sys/param.h is there but does not have MIN/MAX macros. The attached patch explicitly defines MIN and MAX on Solaris. It may be useful to detect the presence of MIN and MAX in sys/param.h and make the definition depend on that. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Provide-implementation-for-MIN-and-MAX-if-system-doe.patch Type: application/octet-stream Size: 1203 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130405/70c28bfc/attachment-0001.obj -------------- next part -------------- Apart from that it seems to compile fine. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
On 1.4.2013 16:04, LRN wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01.04.2013 16:55, Janne Hyv?rinen wrote: >> On 1.4.2013 15:29, LRN wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 01.04.2013 16:24, Janne Hyv?rinen wrote: >>>> I'm worried about some of the modifications done to the UTF-8 >>>> patch. In commit 2199d086921eb37d249cae0731f334556ec6209d >>>> #ifdef checks were changed from specific FLAC__STRINGS_IN_UTF8 >>>> to generic _WIN32 and the specific defines were later removed >>>> in commit 0cd2e9ed6918b782195d0024dd19dcfa39df8f82. >>>> >>>> The reason I had them this way is that FLAC API has public >>>> functions that work with filenames. Default compile options >>>> for FLAC would be unaffected and existing programs that rely on >>>> ANSI filenames would continue to work. The new configuration >>>> option "Release (UTF-8)" was meant to isolate the changes so >>>> that only official bundled frontends that know about the >>>> changes would use them. >>> That's a valid point. >>> >>> Alternative approach (something i saw in libxml2 recently) is to >>> make UTF-8-to-UTF-16 conversion a bit smarter: First try the >>> conversion, assuming the string to be UTF-8-encoded. If that >>> fails, assume the string is in native encoding, and run the >>> conversion function again with appropriate source codepage (when >>> using W32 conversion functions that would be CP_ACP). If that >>> fails, fail the function call as usual. >>> >> I initially had it that way. I just didn't feel comfortable leaving >> it as it could in theory access wrong files. Granted, it would >> require having some rather weird names for files but it's still a >> possibility. >> > Another option is to have a flag in the library, which can be changed > at runtime (by calling a special library function, say, > "flac_set_utf_mode()"). If that flag is set, assume strings to be in > UTF-8. Otherwise assume them to be in local codepage. > > You can still have 2 different builds (UTF-8 one and normal one), they > will just use different default values for that flag. > > Official frontends will know to call flac_set_utf_mode(), and will be > able to work with UTF-8 version regardless of the build. > >These patches change the UTF-8 mode into a runtime choice. The larger patch removes the now obsolete "Release (UTF8)" configuration options from the project files. The smaller patch makes the utf-8 library use ANSI codepage by default. When frontends call the "get_utf8_argv" function it changes Unicode conversion codepage from ANSI to UTF-8. As far as I can see this solves possible issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf8_patches.zip Type: application/x-zip-compressed Size: 4740 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130405/26e2bc0a/attachment-0001.bin
Dagobert Michelsen wrote:> There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors: > > > CC bitreader.lo > > "bitreader.c", line 494: warning: implicit function declaration: MIN > > CC bitwriter.lo > > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern inline function > > "bitwriter.c", line 277: warning: implicit function declaration: MIN > > "bitwriter.c", line 316: reference to static identifier "bitwriter_grow_" in extern inline function > > cc: acomp failed for bitwriter.c > > gmake[4]: *** [bitwriter.lo] Error 1 > > Either bitwriter_grow_ can be made non-static or FLAC__bitwriter_write_zeroes not inline or > also static to work around this. > > The attached patch fixes the issue.Not sure about this patch. Can you please make sure that your C compiler is in the C99 mode and you have optimisation turned on and try again.
Friendly people on Hydrogenaudio found some bugs with the Unicode printing code, so I was forced to make adjustments. While doing testing I noticed that long filenames cause printing bugs on Linux too. If line length on status printing exceeded console length it kept printing the same line over and over. The patch I included fixes encoding side nicely, but on decoding side there is still minor glitch left. On long lines the final status of the decoding will still be printed on its own line. The Unicode printing patch no longer relies on character counts returned by fwprintf function as that didn't match reality. And I switched to use WriteConsole command when output isn't redirected so that special characters can be printed. They were replaced by question marks with fwprintf. Fixing fwprintf output would have required setting console mode to UTF-16 and that would have required all print functions to be replaced by wide char variants. Use of regular ansi function would instantly crash the program in that mode. -------------- next part -------------- A non-text attachment was scrubbed... Name: flac_patches.zip Type: application/x-zip-compressed Size: 2668 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130408/8ab38db2/attachment.bin
On 8.4.2013 21:38, Janne Hyv?rinen wrote:> Friendly people on Hydrogenaudio found some bugs with the Unicode > printing code, so I was forced to make adjustments. > > While doing testing I noticed that long filenames cause printing bugs > on Linux too. If line length on status printing exceeded console > length it kept printing the same line over and over. > The patch I included fixes encoding side nicely, but on decoding side > there is still minor glitch left. On long lines the final status of > the decoding will still be printed on its own line. > > The Unicode printing patch no longer relies on character counts > returned by fwprintf function as that didn't match reality. And I > switched to use WriteConsole command when output isn't redirected so > that special characters can be printed. They were replaced by question > marks with fwprintf. Fixing fwprintf output would have required > setting console mode to UTF-16 and that would have required all print > functions to be replaced by wide char variants. Use of regular ansi > function would instantly crash the program in that mode. >The long line patch is broken and requires much more work, please ignore it. The other patch is still good. Here's a patch to get working Unicode support for one forgotten print function in metaflac. -------------- next part -------------- diff --git a/src/metaflac/utils.c b/src/metaflac/utils.c index 934cfcf..af17d5b 100644 --- a/src/metaflac/utils.c +++ b/src/metaflac/utils.c @@ -136,7 +136,7 @@ void print_error_with_chain_status(FLAC__Metadata_Chain *chain, const char *form va_start(args, format); - (void) vfprintf(stderr, format, args); + (void) flac_vfprintf(stderr, format, args); va_end(args);