Exiv2

On which platform are you working?

If I guess you are using Windows, then I think it'll be OK. If you put exiv2 and the expat DLL into the same directory, then having a different expat DLL on your hard drive shouldn't have any impact. Of course if you want to use exiv2 and wxWidgets in the same application (eg Phatch) then you might have difficulties if the API of expat 2.0.1 is significantly different from 1.95.6. Try it and see, however don't forget to keep your 'old' expat dll so you can restore your system if it doesn't work.

If it doesn't work, please let me know more about your setup and the errors and I'll see what I can do. Here are some options:
1) build exiv2 without XML support (which would remove XMP support)
2) build exiv2 with expat 1.95.6 (I don't know if this will build)
3) upgrade/build wxWidgets to a version which supports 2.0.1
4) build a version of exiv2 (or wxWidgets) which is statically linked with expat

If it does work, can you let us know so that anybody else visiting this page knows you have succeeded.

Robin

I am developing a program that works on Linux, OS X and Windows.

I studied the problem a little more and I realized that expat is only used for XMP support.
Since at the moment I do not need to handle XMP I decided to build exiv2 without xml support. I upgraded exiv2 because I want to handle raw images and the ability to extract the previews is perfect for my purposes.
I already built the program under all the supported operating systems and everything is working fine. I statically linked exiv2 and expat.

In the future I plan to add XMP support, so I will have to solve this problem. Maybe wxWidgets will be updated to the newest expat, otherwise I think that at first I will try and use expat 1.95.6. If it will not work I will try different solutions and you will surely find me back at this forum.

Anyway, I will surely post a message when I will add XMP support.

Thank you for your help.

Fulvio Senore

I studied the problem a little more and I realized that expat is only used for XMP support.

That's right. Since Exiv2 uses the XMP-SDK from Adobe, you might get a better answer from them, maybe here: http://forums.adobe.com/community/design_development/xmp_sdk

Besides, I think it should be possible to link two versions of expat into your program, one for Exiv2 and another version for wxWidget. They would normally be linked with different names, so that should work just fine.

Andreas

Hello Andreas,

thank you for the link, and thank you for exiv2: it is a great tool.

I didn't think of linking two versions of expat. I thought that it would have led to symbols duplication at linking time.

Fulvio

I wasn't accurate. I thought if libexiv2.so has been linked with libexpat.so.1 and libwxwidgets.so with libexpat.so.2, it is possible to link a program with both, libexiv2.so as well as libwxwidgets.so and in turn they both would use their own version of libexpat.

But although that doesn't result in duplicate symbols, it doesn't work anyway. This is what happens (using two versions of libexiv2 instead of libexpat):

Let's build a sample liba.so which uses libexiv2 0.18.99 (trunk):

ahuggel@mowgli> cat a.cpp
#include <exiv2/types.hpp>
#include <iostream>
#include "a.hpp" 

void a()
{
    std::cout << "a(): Compiled with Exiv2 version " << EXV_PACKAGE_VERSION << "\n" 
              << "     Runtime Exiv2 version is    " << Exiv2::version()    << "\n";
}

ahuggel@mowgli> g++ -Wall -fPIC -DPIC -c a.cpp -o a.o
ahuggel@mowgli> g++ -shared a.o -lexiv2 -o liba.so
ahuggel@mowgli> ldd liba.so | grep exiv2
    libexiv2.so.5 => /usr/local/lib/libexiv2.so.5 (0xb7d71000)

And another similar library libb.so which uses libexiv2 0.17

ahuggel@mowgli> cat b.cpp
#include <exiv2/types.hpp>
#include <iostream>
#include "b.hpp" 

void b()
{
    std::cout << "b(): Compiled with Exiv2 version " << EXV_PACKAGE_VERSION << "\n" 
              << "     Runtime Exiv2 version is    " << Exiv2::version()    << "\n";
}

ahuggel@mowgli> ldd libb.so | grep exiv2
    libexiv2.so.4 => /usr/local/lib/libexiv2.so.4 (0xb7e0c000)

liba and libb are linked with different versions of libexiv2 which co-exist on my system. Programs that use either liba or libb also use the respective version of libexiv2, as expected.

Now I can write a program that uses both, liba.so and libb.so

ahuggel@mowgli> cat main.cpp
#include "a.hpp" 
#include "b.hpp" 

int main()
{
    a();
    b();
    return 0;
}

This program compiles and links without complaining about duplicate symbols and seems to be linked with both versions of libexiv2:

ahuggel@mowgli> g++ -Wall -L. -la -lb main.cpp -o main
ahuggel@mowgli> ldd ./main | grep -e b[ab] -e exiv2
    liba.so (0xb7fdd000)
    libb.so (0xb7fda000)
    libexiv2.so.5 => /usr/local/lib/libexiv2.so.5 (0xb7b94000)
    libexiv2.so.4 => /usr/local/lib/libexiv2.so.4 (0xb7a03000)

However, when I run the program, it only uses one version of libexiv2:

ahuggel@mowgli> ./main
a(): Compiled with Exiv2 version 0.18.99
     Runtime Exiv2 version is    0.18.99
b(): Compiled with Exiv2 version 0.17
     Runtime Exiv2 version is    0.18.99

I don't understand why this is so, but it reminds me of some very obscure bugs we saw in digiKam at one point.

Andreas

Merry Christmas to the Huggel Family:

Ah, the joys of linking libraries on Christmas Day. This really interests me - however I haven't time at the moment to investigate. There are debugging environment strings on the mac (man dyld) such as LD_PRINT_LIBRARIES which give more insight to the behavior of the dynamic loader at run time. There's ldconfig on Linux which I've never used. Windows has depends.exe and I distribute a home-made command-line version depends1.exe in the msvc directory for validating the build.

Merry Christmas to Everybody.

Thanks Robin! And Merry Christmas to you and your family too!
Andreas

Andreas,

thank you for taking the time to test this.

I have a better knowledge of Windows than *nix, and I was thinking of static linking. That is why I thought about duplicated symbols.

Fulvio