the difference between a static library and a dynamic(ally linked) library is well known to me. This is not my concern.
I'm trying to understand what is different before and after pulling a new version from github, because from one day to the other our own application can no longer be linked against libraw, but results in errors due to 'undefined symbols', when trying to link against a new build of libraw. This typically occurs, when symbols are not flagged to be exported at compile time, or when the signature of methods in libraries do not match due to different naming conventions.
So I'm trying to understand the problem of 'undefined symbols' from the newly built libraw, esp. a missing main entry point 'LibRaw::open_file', which the linker complains 'undefined symbol' now in the static libraw.
According to your suggestion, I checked the locations where both, dynamic and static verisons of libraw reside after build:
The directory 'lib' in the code repository of libraw is created during the build process of libraw. There is no dynamic library version of libraw created and placed in this directory. In fact, the build process creates another hidden subdirectory, where both the static and dynamic libraries are compiled and linked. These then are placed at different locations during 'make install'.
I also tried to remove the created shared library twin of libraw from the system, with no success. The linker still complains about 'undefined symbols'.
An explicit path is set to this directory via option '-L' pointing to the directory 'lib' of the code repository, when linking our code to the static libraw.a. So the linker typically should not fetch a different version from any different location.
What I do not understand: The way we use libraw didn't change since months, as the Makefile to compile our own wrapper library didn't change, as well.
I checked the status of our work, how it was on the specific developer machine before and after pulling the recent version of libraw, by playing back a full back up of the operating system. Three days ago, before pulling the current work from github, there was such no problem of having undefined symbols when linking against the static version of libraw. Now the same makefile and build process can no longer link against a newer build of libraw.
No clue, what is wrong, except, we pulled a new version of the code repository of libraw from github.
Hi Alex,
the difference between a static library and a dynamic(ally linked) library is well known to me. This is not my concern.
I'm trying to understand what is different before and after pulling a new version from github, because from one day to the other our own application can no longer be linked against libraw, but results in errors due to 'undefined symbols', when trying to link against a new build of libraw. This typically occurs, when symbols are not flagged to be exported at compile time, or when the signature of methods in libraries do not match due to different naming conventions.
So I'm trying to understand the problem of 'undefined symbols' from the newly built libraw, esp. a missing main entry point 'LibRaw::open_file', which the linker complains 'undefined symbol' now in the static libraw.
According to your suggestion, I checked the locations where both, dynamic and static verisons of libraw reside after build:
The directory 'lib' in the code repository of libraw is created during the build process of libraw. There is no dynamic library version of libraw created and placed in this directory. In fact, the build process creates another hidden subdirectory, where both the static and dynamic libraries are compiled and linked. These then are placed at different locations during 'make install'.
I also tried to remove the created shared library twin of libraw from the system, with no success. The linker still complains about 'undefined symbols'.
An explicit path is set to this directory via option '-L' pointing to the directory 'lib' of the code repository, when linking our code to the static libraw.a. So the linker typically should not fetch a different version from any different location.
What I do not understand: The way we use libraw didn't change since months, as the Makefile to compile our own wrapper library didn't change, as well.
I checked the status of our work, how it was on the specific developer machine before and after pulling the recent version of libraw, by playing back a full back up of the operating system. Three days ago, before pulling the current work from github, there was such no problem of having undefined symbols when linking against the static version of libraw. Now the same makefile and build process can no longer link against a newer build of libraw.
No clue, what is wrong, except, we pulled a new version of the code repository of libraw from github.
Best,
Thilo