Import error : undefined symbol

[kevin]

Using exiv-0.22 and pyexiv-0.3.2 on Centos 6.x I get this:

>>> import pyexiv2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/pyexiv2/__init__.py", line 60, in <module>
    import libexiv2python
ImportError: /usr/lib64/python2.6/site-packages/libexiv2python.so: undefined symbol: _ZNK5Exiv29Iptcdatum6recordEv

[Olivier Tilloy (osomon)]

Did you get exiv2 and pyexiv2 from official packages for Centos, or did you compile them yourself?

For the record, according to c++filt, the undefined symbol is:

    Exiv2::Iptcdatum::record() const

This issue looks vaguely familiar, a similar problem was reported at http://dev.exiv2.org/issues/627. However Iptcdatum::record() is not virtual.

[kevin (keg)]

I've tried Installing the exvi2 package from the centos 6.x repo but got an error when trying to build up pyexiv2(I don't know of a official pyexiv2 package for centos, is there one?) because the version of exiv2 was 0.18.2-2.1.el6 and resulted in:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/exiv2wrapper.os -c -fPIC -I/usr/include/python2.6 src/exiv2wrapper.cpp
src/exiv2wrapper.cpp: In member function 'const std::string exiv2wrapper::Image::getIptcCharset() const':
src/exiv2wrapper.cpp:524: error: 'class Exiv2::IptcData' has no member named 'detectCharset'
scons: *** [build/exiv2wrapper.os] Error 1
scons: building terminated because of errors.

After receiving the error above I tried compiling both from source which resulted in the import error.

[Olivier Tilloy (osomon)]

Kevin,
Sorry for the delay in answering.

Recent releases of pyexiv2 (and the trunk branch) require libexiv2 ≥ 0.19 (see http://tilloy.net/dev/pyexiv2/developers.html#dependencies for a complete list of dependencies), which explains why compilation failed with exiv2 0.18.2-2.1.el6.

Regarding the import error you’re getting when compiling both from source, it might be that pyexiv2 was correctly compiled against the most recent libexiv2, but at runtime it picks up the incorrect (old) version. Can you make sure the old (packaged) version of exiv2 is uninstalled, before you install the one you compiled from source? Also, after building pyexiv2 from source, can you paste here the output of `ldd build/libexiv2python.so` ?

Thanks!

[kevin (keg)]

Hi Olivier,

I cleaned/removed all instances of exiv and pyexiv and recompiled from exiv2-0.22 and pyexiv-0.3.2 and got a import error of:
>>> import pyexiv2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/pyexiv2/__init__.py", line 60, in <module>
    import libexiv2python
ImportError: libexiv2.so.11: cannot open shared object file: No such file or directory
>>> import pyexiv2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/pyexiv2/__init__.py", line 60, in <module>
    import libexiv2python
ImportError: libexiv2.so.11: cannot open shared object file: No such file or directory

ldd output is:
$ ldd build/libexiv2python.so
 linux-vdso.so.1 => (0x00007fffaddc8000)
 libboost_python.so.5 => /usr/lib64/libboost_python.so.5 (0x00007fddd3ffe000)
 libexiv2.so.11 => not found
 libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fddd3cf7000)
 libm.so.6 => /lib64/libm.so.6 (0x00007fddd3a73000)
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fddd385d000)
 libc.so.6 => /lib64/libc.so.6 (0x00007fddd34cc000)
 libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007fddd3113000)
 /lib64/ld-linux-x86-64.so.2 (0x0000003c9d200000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fddd2ef7000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007fddd2cf2000)
 libutil.so.1 => /lib64/libutil.so.1 (0x00007fddd2aef000)

Thanks!

[Olivier Tilloy (osomon)]

Right, this is because libexiv2 is not installed system-wide. You can fix that by either installing it system-wide (`make install` after building it), or by setting the LD_LIBRARY_PATH environment variable to contain the directory that contains libexiv2.so.11 (usually ./src/.libs/ if you built it from source).

[kevin (keg)]

I think your suspicions about my original problem were correct.

After fixing the shared library dependencies things seem to be working properly. To note, I had installed the exiv libraries system-wide, but centos didn't know where to look. Adding the paths to /etc/ld.so.conf did the trick.

Thanks for the help!

[Olivier Tilloy (osomon)]

Excellent, I’m glad we’ve managed to figure it out.
I’m marking this bug as invalid then, feel free to re-open if similar problems resurface.