search for: fopen_utf8

...ther programs nor would they > benefit from it without doing the extra work of converting their ansi > filenames and functions to utf-8. libFLAC.a(metadata_iterators.release.o): In function `simple_iterator_prime_input_': flac/src/libFLAC/metadata_iterators.c:427: undefined reference to `fopen_utf8' flac/src/libFLAC/metadata_iterators.c:424: undefined reference to `fopen_utf8' libFLAC.a(metadata_iterators.release.o): In function `set_file_stats_': flac/src/libFLAC/metadata_iterators.c:3355: undefined reference to `chmod_utf8' flac/src/libFLAC/metadata_iterators.c:3356: undefin...

...tic, win_utf8_io_static Both 'libFLAC_static' and 'libFLAC_dynamic' projects depend (only) on 'win_utf8_io_static'. I tried to remove this dependency and libFLAC_dynamic failed to compile since metadata_iterators.c uses e.g. flac_fopen, which is defined in share/compat.h as fopen_utf8. metadata_iterators.obj : error LNK2001: unresolved external symbol unlink_utf8 metadata_iterators.obj : error LNK2001: unresolved external symbol fopen_utf8 metadata_iterators.obj : error LNK2001: unresolved external symbol utime_utf8 metadata_iterators.obj : error LNK2001: unresolved...

Janne Hyv?rinen wrote: > Win_utf8 stuff should not be included in libflac since it's only to be > used by the flac.exe frontend. It is not needed by other programs nor > would they benefit from it without doing the extra work of converting > their ansi filenames and functions to utf-8. > >> Version 2 of my patch attached, which fixes the problem for the >>

On 18.3.2013 12:25, Erik de Castro Lopo wrote: > 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. > +1 > > Erik Alright, here's

HI all, I think its time for a new release. The current code base is stable and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been building regularly on their platforms of interest. I made a first pass on an update to the changelog.html. I' also putting toether a release checklist that I will add

..._encode_file" I get a lot of linker errors. I checked linker/input/additional dependencies and added the paths for libFLAC, libFLAC++ and corrected the path for libogg. Now I'm just getting one link error: libFLAC_static.lib(stream_encoder.obj) : error LNK2001: unresolved external symbol _fopen_utf8 Any help would be much appreciated. Thanks, Matt

...all 3rd-party programs that use libFLAC cannot enable UTF-8 support and send UTF8-encoded filenames to libFLAC functions; all filenames must be in a default codepage instead. And they (directly or indirectly) link with win_utf8_io despite the fact that they cannot use it. (Actually the use it, but fopen_utf8() behaves for them as plain fopen(). It just unnnecessarily calls malloc/free and MultiByteToWideChar. Correct me if I'm wrong).

lvqcl wrote: > Then IMHO all three build systems (configure && make, Makefile.lite > and MSVC) should be synchronized with each other +1 > TO ERIK: > > I have some patches, but they either modify MSVC .vcxproj files, > or win_utf8_io.c/.h, so they conflict with patches from Evan Ramos. > So should they be applied? rejected? postponed until after flac 1.3.2? We

...hen fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently functions in win_utf8_io.c are a compatibility layer for libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC.

...lip out the door while I'm busy. > Should the following #if defined _MSC_VER || defined __MINGW32__ be simplified to #ifdef WIN32 ? Alternatively _WIN32. Since it's win32 and not something compiler specific. As for the macros: +#define flac_vfprintf vfprintf_utf8 +#define flac_fopen fopen_utf8 +#define flac_stat _stat64_utf8 ... I leave this up for Erik to decide, though I would have preferred not using rename macros at all. Not sure if these were intended: +#include <sys/stat.h> /* for flac_stat() */ +#include <sys/utime.h> /* for flac_utime() */ +#include <io.h> /*...

...ne 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 *fi...

...se undocumented functions from shared libFLAC library, why not. They won't be officially available to 3rd-party apps, only to flac/metaflac/etc. And BTW, flac built with MSYS/MinGW-w64 (with --enable-shared option) *DOES EXACTLY THIS*: libFLAC-8.dll exports chmod_utf8, CreateFile_utf8 at 28, fopen_utf8, win_get_console_width, and so on, and flac.exe imports them from libFLAC-8.dll.

...| defined __MINGW32__ > > be simplified to > #ifdef WIN32 > > ? Alternatively _WIN32. Since it's win32 and not something compiler > specific. Indeed. Not sure what I was thinking. > > As for the macros: > +#define flac_vfprintf vfprintf_utf8 > +#define flac_fopen fopen_utf8 > +#define flac_stat _stat64_utf8 > ... > > I leave this up for Erik to decide, though I would have preferred not > using rename macros at all. I think this is the sanest way. Only few #ifdefs instead of wrapper functions filled with them that do essentially nothing on *nix. >...

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