Hi all,
I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if
this is the right place to submit patches, but someone suggested this on
the apparently dead SourceForge patch tracker.
The first two are quite straight forward:
- The ICL patch fixes a typo in bitmath.h and add
Timothy B. Terriberry wrote:
> _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 mea
JonY wrote:
> How about just forgetting about base XP and require at least SP2 or some
> such? Alternatively, use win32api underneath instead, eg
> CreateFileW/SetFilePointer.
Even SP2 and SP3 do not have fseeki64/ftelli64. Using Windows API
functions would probably be the cleanest solution, but o
Timothy B. Terriberry wrote:
> Instead I've attached a patch that uses fgetpos/fsetpos. This is
> totally untested (I haven't even checked it compiles), but the idea
> should work.
MSDN says "The pos value is stored in an internal format and is intended
for use only by *fgetpos* and *fsetpos*."
Timothy B. Terriberry wrote:
>> "The pos value is stored in an internal format and is intended
>> for use only by *fgetpos* and *fsetpos*."
> FWIW, I verified that this is the approach used by mingw32 to implement
> fseeko/ftello.
>
Yes, they do - I also had a look at the libmingwex source. But sti
Janne Hyvärinen wrote:
> Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005. FLAC
> is also configured to be compiled with static linking, so no external
> dependencies hinder its function.
Ok. Thanks for pointing this out!
I use a custom build setup and link dynamically against msvc
Source and destination buffers are in the wrong order in your call to
memcpy. Argument order must be dest, src, size instead of src, dest, size.
Am 02.07.2013 17:24, schrieb Burak Orçun Özkablan:
> *// copy buffer array to m_pile_array*
> *if(input_pile_size > 0) {*
> *memcpy(input_pile_array, bu
Hi all,
There's a typo in the conditional to check the exit condition in
ascii_strcasecmp in share/utf8/charset.c. It checks for (!*s1 || !*s1)
instead of (!*s1 || !*s2). Attached patch fixes this.
Note that the typo did not affect the result of the function as the loop
is exited before chan
Am 03.06.2014 16:45, schrieb lvqcl:
> 2) to ALL:
> I attached a small program. Compile and run it.
> * Does it work correctly when compiled with -O3 -msse2 options?
> * If yes, does it work correctly when compiled with -O3 -funroll-loops
> -msse2 options?
> ( and what is the version of your GCC?
Am 03.06.2014 16:45, schrieb lvqcl:
2) to ALL:
I attached a small program. Compile and run it.
* Does it work correctly when compiled with -O3 -msse2 options?
* If yes, does it work correctly when compiled with -O3 -funroll-loops
-msse2 options?
( and what is the version of your GCC? )
I fur
FILE pointer in "rb" mode.
This should help.
BR, Robert
----
Robert Kausch
robert.kau...@freac.org
Am 07.12.2016 um 19:58 schrieb Luke Bradford:
Hi all,
Thanks in advance for your help, and sorry for the slow reply. I've
created a small OS X example project
<https://
ld make it
work again on most systems. Tested on Windows (MSYS) and Ubuntu 12.10.
The main issues were inclusion of non-existing Makefile.deps, missing
PACKAGE_VERSION define and wrong build order (i.e. trying to build flac
before libFLAC and other dependencies).
Robert Kausch
robert.kau
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
uname -s) 1
10)"=="MINGW32_NT"];|' and set EXE=.exe in that case instead of
generating the file from common.sh.in.
Robert Kausch
robert.kau...@freac.org
diff -Naur flac-1.3.2pre2/build/config.mk flac-1.3.2pre2+litefix/build/config.mk
--- flac-1.3.2pre2/build/config.mk 2016-12-1
ssues. Parallel
encoding with flac.exe also should be no problem as every instance of
flac.exe is a separate process.
I'll do some more tests with pre3 later today.
----
Robert Kausch
robert.kau...@freac.org
___
flac-dev mailing list
flac-dev@xip
ed my tests now.
I found no issues converting to and from FLAC in parallel with 10
threads/processes using either libFLAC.dll or flac.exe. All good, just
as expected.
Robert Kausch
robert.kau...@freac.org
___
flac-dev mailing list
flac-dev@xip
Hi Martijn,
Great work!
I concur with David that compression should work the same on all
platforms. There can be SIMD optimizations for some routines, but they
should produce the same result as the non-SIMD versions. If outdated
optimizations cannot be updated, better drop them instead of kee
the different instances of the
compiler define the correct macros for the respective architecture being
compiled. No need to work around any build-system logic doing its own thing.
Robert
Robert Kausch
robert.kau...@freac.org
Am 18.09.2022 um 16:39 schrieb brianw:
Ah, yes, the preprocessor
18 matches
Mail list logo
