similar to: Include directories

lvqcl wrote: > IIRC libFLAC.a built with "./autogen.sh && ./configure && make" > contains all functions from win_utf8_io. So I think it's possible > to change some Makefile.lite or maybe build/*.mk files so that > there will be no need to add -lwin_utf8_io to -lFLAC. Version 2 of my patch attached, which fixes the problem for the Makefile.lite and Visual

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share:

On Mon, Jun 16, 2014 at 4:10 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > Erik de Castro Lopo wrote: > >> Ok, done for the autotool build system. Would appreciate it if someone >> could look that the VS build files. > > > I'll do it, but: I cannot build 32-bit flac with MinGW: > > <-------------------------------------------------------------> >

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. -- Janne On 9.1.2016 5.08, Evan Ramos wrote: > lvqcl wrote: > >> IIRC libFLAC.a built with "./autogen.sh &&

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add

Hi all, New pre-release here is at: http://mega-nerd.com/tmp/flac-1.3.2pre2-win.zip http://mega-nerd.com/tmp/flac-1.3.2pre2.tar.xz Changes: * Fix PACKAGE_VERSION in MSVS project files. * Fix Makefile.lite in tarball (make test is still failiing). MD5 and SHA256 sums: > md5sum flac-1.3.2pre2* e276e3a9e99ae07f4bd25278f533b9e5 flac-1.3.2pre2.tar.xz

Am 08.12.2016 um 20:44 schrieb Brian Willoughby: > On Dec 8, 2016, at 12:59 AM, Dave Yeo <dave.r.yeo at gmail.com> wrote: >> On 12/08/16 12:24 AM, Thomas Zander wrote: >>> On 7 December 2016 at 21:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >>>> lvqcl.mail wrote: >>>> >>>>> "make -f Makefile.lite" also

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 >

Erik de Castro Lopo wrote: > Patch applied, thanks! Glad to help! > Out of curiosity, what platform and compiler are you using? I ask, > because the Makefile.lite system tries to build the project in > src/utils/flactimer under Linux, but that program is meant to be > windows only. I use Windows as a host (I have Win7 x64 and Win8.1 x64 machines). My compilers of choice are MinGW

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

Evan Ramos wrote: > > Yes please. > > Patch attached. Sorry, I misunderstood your intention. The utf8_static library should stay as a separate component, but should be statically linked as needed (ie its only needed for Windows) Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) > CCLD utf8/libutf8.la > CC win_utf8_io/win_utf8_io.lo > win_utf8__io/win_utf8_io.c:266:13: error: static declaration > of 'set_filename_utf8' follows

-----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

Currently it is required to include share/compat.h before inclusion of share/win_utf8_io.h. That's because of print_console() declaration: its 3rd argument have type 'uint32_t' which is defined in share/compat.h. So share/win_utf8_io.h depends on share/compat.h which in turn includes share/win_utf8_io.h. Not a problem but it's a bit ugly imho. Actually, the 3rd argument of

Am 11.12.2016 um 00:05 schrieb lvqcl.mail: > Robert Kausch wrote: > >> The main issues were inclusion of non-existing Makefile.deps > > It does exist in git, but not in flac-1.3.2pre1.tar.xz. > > (Here's the list of all files that exist in git but not in > the pre-release tarball: > > .gitignore > Makefile.deps > ci\flac-autotool.sh > doc\isoflac.txt

Am 11.12.2016 um 11:35 schrieb Erik de Castro Lopo: > New pre-release here is at: > > http://mega-nerd.com/tmp/flac-1.3.2pre2-win.zip > http://mega-nerd.com/tmp/flac-1.3.2pre2.tar.xz > > Changes: > > * Fix PACKAGE_VERSION in MSVS project files. > * Fix Makefile.lite in tarball (make test is still failiing). Thank you for providing a second preview!

lvqcl wrote: > all I can suggest > is to apply this patch, then 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

lvqcl 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

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work