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 defines. Now I see what you're
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
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@xiph.org
. 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@xiph.org
http
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-11 10:24:00 +000
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
for the Makefile.lite build system that should 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 depend
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://drive.goog
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
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
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,
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 still,
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
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 on
14 matches
Mail list logo
