The Oyranos project has some plugins, which work as shared libraries. These libraries need to link in libraw.a, in order to use the LibRaw functionality for conversion and ICC profile assignment.
However on 64-bit machines the gcc compiler says:
linux/bin/ld: /usr/lib64/libraw.a(lib_libraw_a-libraw_cxx.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
Attached you can find a patch that fixes the following problems with the pkg-config files:
* The version number was fixed at 0.9.1. It is now taken from ./version.sh.
* The "Requires:" field was fixed to "lcms" even if lcms2 or nothing is used. It is now set to "lcms", "lcms2" or empty as appropriate.
* The lcms dependency libraries were duplicated in the "Libs" field. This is not necessary, the "Requires" field takes care of that.
The application I am working on (Luminance HDR) crashes trying to decode a RAW image from SIGMA DP1 camera (file extension .X3F).
Library version is LibRaw-0.12.0-Beta4 with LibRaw-demosaic-pack-GPL2-0.12.0-Beta4
Here is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeab37710 (LWP 21659)]
LibRaw::foveon_interpolate (this=0x7fffeab09ad0) at ../LibRaw-demosaic-pack-GPL2-0.12.0-Beta4/dcraw_foveon.c:389
389 FORC3 ddft[i+1]
[1] += (short) image[row*width+col][c];
Hope this can help you
(I'm not sure where this post belongs. I started to put it in general but that area seems overrun by watch spam.)
I've recently worked with a couple of industrial cameras based on the Sony ICX 625/655 5MP color sensor. I modified libraw to work with these images, and the patch is below. The JAI BB-500GE wasn't tested, but should work OK because the GigE camera is nearly identical to the CameraLink, which was tested. The other 3 were tested and work OK.
Hi,
the company that I work for has now paid for and received a patch from Dave Coffin for new image pixel cropping functionality. We are C++ programmers and are eager to get this new code integrated into LibRaw as soon as possible, so if we can be of any help please let us know. Also, we may be available to assist in the future development of LibRaw. Can someone please reply back as soon as possible please as to how we may move these plans forward?
Thanks,
Patrick
Have you all considered a modified LGPL like what fltk has?
The only thing they've added to the LGPL is to allow for static linking.
This is desirable for
- platforms that don't support dynamic libraries
- easier package deployment on systems that don't look for the shared library in the executable directory by default.
This does not occur, when I make the free-function defined in the libraw class public and use it to free the memory. What is the cause and solution to this problem?
Recent comments