I've had issues getting OpenMP going on the Mac, both on a 10.6 / XCode3 system and on a 10.7 / XCode 4 system. The configure script says it's not available, but it is. FWIW, I can work around this by changing the configure script's sample OpenMP code (line 15359) to:
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
#include "omp.h"
int
main ()
{
omp_set_num_threads (2);
int count;
I was wondering, is libraw multithreaded when calling unpack()?
I would like to be able to use all cores on the tablet I am developing for, and am wondering if there is something to do about the speed on those limited devices?
I am trying to compile LibRaw for android, but I am getting stuck.
I downloaded the ndk, setup a standalone toolchain for android-9, added that bin folder as first to my path,
and ran ./configure --host=arm-linux-androideabi
I did need to update the config.sub file since it was very old and did not recognize this host setting. After that it completely ran ./configure and I tried to run make.
Here it however failed fast:
LibRaw-0.14.4$ make
depbase=`echo internal/dcraw_common.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
When LIBRAW_LIBRARY_BUILD is defined, the function smal_decode_segment() uses the uninitialized variable "row" in the latest 14.4 release, and in github.
The misuse of the uninitialized variable is at line 3094 in the 14.4 version, or line 3101 in the current code on github.
I've used an old "lite" version and am looking to expand my use of LibRAW. In the end, I'll want to try to get things compiled up as a Universal Binary for 10.4+ and on Windows, but for now, I'm just looking to get things up and going. I'm on OS X version 10.6.7 and XCode version 3.2.2. Since you've got it compiling on OS X already, this is likely due to different XCode versions or a brain lapse on my part. But, here's what I'm getting:
./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
When converting an image with highlight recovery (without blending) and automatic white balance with libraw 0.13.5, we see major artifacts being introduced in areas.
Testing with the same version of dcraw shows no problem; it sounds like highlight recovery incorrectly occurs at the wrong position in the pipeline.
Recent comments