Visual Studio is able to upgrade projects from older version to new one. Provided vcproj files are compatible with VS up to 2013 (have not tested 2015 version).
Is there any problem with project upgrade with VS2015?
Could you please add a Visual Studio 2015 solution? VS community 2015 is already free now. It will be great to have a VS 2015 solution that can build with no error.
My goal is to implement custom IO (using GIO, Gnome/GLib IO stack) for the RAW file loader of GEGL (Gimp new engine, which is C code). As of today, the only possibility is to use open_buffer() on a piece of memory previously populated by GIO machinery, but this requires the entire file/steam to be buffered... I can share a diff showing how the proposed LibRaw_proxy_datastream is intended to be used in my work in progress RAW loader if you want.
Looks interesting in general, although I cannot imagine C-API user with own IO-callback written (usual C-API usage is embedding into other programming environment such as Python or Matlab or Delphi).
Is there a way to see diff against master branch in gitlab without logging in? Cannot find this button in 30-sec look.....
If your changes do not require patching main Libraw code, the best place to store it is Libraw-contrib repo, not the upstream (we're very careful with upstream, because after upstream import we need to support imported code; it is much better to keep it separately without any warranties)
Thanks for your patience and answers. The problem was in zlib. So I decided to do what you said I build zlib by zlib's win32\Makefile.msc using VS x64 Native tools shell. It generated a lot of libs
Without this define
DllDef is defined as:
__declspec( dllexport ) - for DLL build
and as
__declspec( dllimport ) - for your app build.
So, it works as expected: DLL exports symbols and your app imports it.
If you define LIBRAW_NODLL (for both library build and for your app build)
DllDef is defined as empty string.
So, in library this is 'just' usual functions (without extra dllexport attributes)
And your app expects just usual functions, not dllimport
if you're using win32\Makefile.msc doesn't that mean that the build will be for 32bit systems? Can you later link to a x64 project?
If not, is there a way around the issue or should I just use the latest release?
I think I managed to overcome my previous problem, and build LibRaw, but when I try to link it to my VS project I g and compile it can't find the definitions of functions I'm trying to use. e.g.
: error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z) referenced in function myFunction
Please use
1) release library (LibRaw 0.17), not development branch
2) Build the static library using
nmake -f Makefile.msvc
and use lib\libraw_static.lib for your application.
So I've managed to build the libraries, but when I try to link to my project I am getting the following errors
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z) referenced in function GetColordataBlack
Sorry, no Linux on hands, so could not check the advice:
1) ./configure --enable-shared=no
2) make clean && make # to rebuild
This will remove shared (.so) libraries and will build static (.a) instead
Than build your sample.
If you have installed libraw libraries somewhere in system (/usr/local/lib or so) you may need to deinstall it
There is no EXIF data block in LibRaw data (some EXIF values are parsed into imgdata.other fields).
Starting from LibRaw 0.17 you can install own EXIF/Metadata parser callback which will receive all tags at parse time.
Visual Studio is able to upgrade projects from older version to new one. Provided vcproj files are compatible with VS up to 2013 (have not tested 2015 version).
Is there any problem with project upgrade with VS2015?
Could you please add a Visual Studio 2015 solution? VS community 2015 is already free now. It will be great to have a VS 2015 solution that can build with no error.
Thanks for the diff link.
It looks like no Libraw patching required, so entire project may exists separated from libraw upstream.
So, please separate your changes from libraw source and we'll put it into https://github.com/LibRaw/LibRaw-contrib repo (contact us when you're ready)
Thanks for your feedback. Think you can access the diff here, even without being logged in:
https://gitlab.com/tchaik/LibRaw/commit/0e83b1278d8794513949ffed3f7de4a7...
My goal is to implement custom IO (using GIO, Gnome/GLib IO stack) for the RAW file loader of GEGL (Gimp new engine, which is C code). As of today, the only possibility is to use open_buffer() on a piece of memory previously populated by GIO machinery, but this requires the entire file/steam to be buffered... I can share a diff showing how the proposed LibRaw_proxy_datastream is intended to be used in my work in progress RAW loader if you want.
Looks interesting in general, although I cannot imagine C-API user with own IO-callback written (usual C-API usage is embedding into other programming environment such as Python or Matlab or Delphi).
Is there a way to see diff against master branch in gitlab without logging in? Cannot find this button in 30-sec look.....
If your changes do not require patching main Libraw code, the best place to store it is Libraw-contrib repo, not the upstream (we're very careful with upstream, because after upstream import we need to support imported code; it is much better to keep it separately without any warranties)
We'll put next 'massive update' on Github in March or so.
Thank you very much, it all worked.
I just noticed that the post about LibRaw 18 is three months old, were there any significant changes to the source since then?
I guess, zlib.lib *only* is enough.
Thanks for your patience and answers. The problem was in zlib. So I decided to do what you said I build zlib by zlib's win32\Makefile.msc using VS x64 Native tools shell. It generated a lot of libs
minizip.lib
miniunz.lib
testzlibdll.lib
zlibstat.lib
testzlib.lib
zlibwapi.lib
zlib.lib
zdll.lib
Now I should add everything except zdll.lib and testzlib.dll to my LibRaw build ?
uncompress() is from zlib (library or DLL)
That resolved several issues. Thanks. I still can't properly compile though. It throws errors such as
libraw.lib(libraw_cxx.obj) : error LNK2019: unresolved external symbol uncompress referenced in function "protected: void __cdecl LibRaw::deflate_dng_load_raw(void)" (?deflate_dng_load_raw@LibRaw@@IEAAXXZ)
\Working-pc-13882-12680-2708-1\RAWTools.dll : fatal error LNK1120: 1 unresolved externals
CreateLibrary::cmperr: Compile error: libraw.lib(libraw_cxx.obj) : error LNK2019: unresolved external symbol uncompress referenced in function "protected: void __cdecl LibRaw::deflate_dng_load_raw(void)" (?deflate_dng_load_raw@LibRaw@@IEAAXXZ)
CreateLibrary::cmperr: Compile error: C:\Users\HP\Documents\rawtools\build\RAWTools\LibraryResources\Windows-x86-64\Working-pc-13882-12680-2708-1\RAWTools.dll : fatal error LNK1120: 1 unresolved externals
This is preprocessor option, of course.
Without this define
DllDef is defined as:
__declspec( dllexport ) - for DLL build
and as
__declspec( dllimport ) - for your app build.
So, it works as expected: DLL exports symbols and your app imports it.
If you define LIBRAW_NODLL (for both library build and for your app build)
DllDef is defined as empty string.
So, in library this is 'just' usual functions (without extra dllexport attributes)
And your app expects just usual functions, not dllimport
I'm not sure I understand, is LIBRAW_NODLL a pre-processor or linker option? The dllDef is defined just as DllDef if LIBRAW_NODLL is defined.
For static build you need to define LIBRAW_NODLL for both library build and library use.
The trick is in libraw/libraw_types.h (see how DllDef is defined)
I use static /MT build. I am using Ant build and not visual studio shell.
win32\Makefile.msc works ok for both 32 and 64 builds. Just use it from corresponding Visual studio shell (32 or 64-bit).
Link error: do you use LibRaw as static or as dynamic (dll) build?
Thank you for your answer,
if you're using win32\Makefile.msc doesn't that mean that the build will be for 32bit systems? Can you later link to a x64 project?
If not, is there a way around the issue or should I just use the latest release?
I think I managed to overcome my previous problem, and build LibRaw, but when I try to link it to my VS project I g and compile it can't find the definitions of functions I'm trying to use. e.g.
: error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl LibRaw::LibRaw(unsigned int)" (__imp_??0LibRaw@@QEAA@I@Z) referenced in function myFunction
In our Windows programs (RawDigger, FastRawViewer) we use zlib build by zlib's win32\Makefile.msc
No extra zlibwapi.lib is used, just zlib.lib (not zdll.lib which points to zlib.dll)
I just added include path to build specification, but I'm still getting the same error.
Sorry, I cannot continue this way.
Please use
1) release library (LibRaw 0.17), not development branch
2) Build the static library using
nmake -f Makefile.msvc
and use lib\libraw_static.lib for your application.
I didn't define it as LIBRAW_NODLL, but even after fixing that the same errors remain.
#ifdef WIN32
#ifdef LIBRAW_NODLL
# define DllDef
#else
# ifdef LIBRAW_BUILDLIB
# define DllDef __declspec( dllexport )
# else
# define DllDef __declspec( dllimport )
# endif
#endif
#else
# define DllDef
#endif
this how the libraw_types now looks like
Have you defined LIBRAW_NODLL on library and your application build?
If not, LibRaw will link as dllexport, while your app expect it as dllimport (more details are in libraw_types at DllDef define)
Hi again,
So I've managed to build the libraries, but when I try to link to my project I am getting the following errors
main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl LibRaw::open_file(char const *,__int64)" (__imp_?open_file@LibRaw@@QEAAHPEBD_J@Z) referenced in function GetColordataBlack
and more like it, what might be the issue?
Sorry, no Linux on hands, so could not check the advice:
1) ./configure --enable-shared=no
2) make clean && make # to rebuild
This will remove shared (.so) libraries and will build static (.a) instead
Than build your sample.
If you have installed libraw libraries somewhere in system (/usr/local/lib or so) you may need to deinstall it
Pages