Quote:
|
Originally Posted by scotty1024
As I wrote, it finds the library, it just can't find anything to bind to in it. If I "rm /usr/local/arm/oe/arm-linux/lib/libdjvulibre.so" then try to link it complains that the library is missing.
And yet when the library is there I get:
Code:
main.o(.gnu.linkonce.r._ZTV14DjVuSimplePort+0x14): undefined reference to `DjVuPort::id_to_url(DjVuPort const*, GUTF8String const&)'
|
Both idjvu and libdjvulibre.so are c++ programs, so to be able to link them it's necessary to compile them using the same c++ compiler (sorry, there is no ABI stability for c++). At least, I think that this is what is causing you headaches.
So, you have to recompile libdjvulibre.so using the same toolchain that compiles idjvu.
Rationale: the name mangling algorithm to encode function names plus the classes to which they belong changes between different revisions of the g++ compiler to avoid problems of linking between incompatible versions of the ABI (aplication binary interface) of the generated objects, AFAIK.
An alternative solution is to declare an 'extern "C" { /* ... */ }' API for djvulibre.so using the C++ functions, so you export C functions, and those doesn't need to be mangled, have and stable ABI, so they always work.
(Rant)
As a matter of fact, I don't know why there are libraries distributed that export methods as c++ implementations. I sincerely expect libraries to export C APIs, independently of the language in which they're implemented. And if you want to have a C++ API, it's almost trivial to distribute a thin wrapper (c++ bindings) to be compiled with the program so that it present classes to the library user...
That is, if you're not using KDE. If you use KDE, libraries are c++ and you recopile everything whenever you update your compiiler X-).
(End of rant)