Bug 496050 - import of pyexiv2 is failing
Summary: import of pyexiv2 is failing
Alias: None
Product: Fedora
Classification: Fedora
Component: pyexiv2
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matěj Cepl
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 494419
TreeView+ depends on / blocked
Reported: 2009-04-16 09:52 UTC by kushaldas@gmail.com
Modified: 2018-04-11 13:48 UTC (History)
5 users (show)

Fixed In Version: 0.18.2-2.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-08-08 19:23:44 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Launchpad 370751 0 None None None Never

Description kushaldas@gmail.com 2009-04-16 09:52:28 UTC
Description of problem: One can not import pyexiv2 

Version-Release number of selected component (if applicable): 


How reproducible:
Open pyhton terminal, then try to import pyexiv2

Actual results:

[kdas@d80 ~]$ python
Python 2.6 (r26:66714, Mar 17 2009, 11:44:21)
[GCC 4.4.0 20090313 (Red Hat 4.4.0-0.26)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyexiv2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/pyexiv2.py", line 60, in <module>
    import libexiv2python
ImportError: /usr/lib/python2.6/site-packages/libexiv2python.so: undefined symbol: _ZNK5Exiv29Exifdatum6typeIdEv

Expected results:
Should not show any error

Additional info:

Tried to find what that symbol is using c++filt

[kdas@d80 ~]$ c++filt _ZNK5Exiv29Exifdatum6typeIdEv
Exiv2::Exifdatum::typeId() const

Which is supposed to come exiv2-libs I guess

Comment 1 Matěj Cepl 2009-04-16 19:20:35 UTC
yes, working on upgrade

*** This bug has been marked as a duplicate of bug 494419 ***

Comment 2 Matěj Cepl 2009-04-16 22:19:24 UTC
Actually, if my reading of /usr/include/exiv2/exif.hpp is correct, then this symbol should be really in /usr/lib64/libexiv2.so.5.2.0, but it doesn't seem to be there:

[matej@viklef devel]$ readelf -a /usr/lib64/libexiv2.so.5.2.0 \
    |grep Exifdatum.*typeId
[matej@viklef devel]$ 

Reassigning, but willing to be proven wrong.

Comment 3 kushaldas@gmail.com 2009-04-17 02:45:43 UTC
if we compile the exiv2-libs locally then we can see that symbol, but if the same file comes from a RPM then it is not there. I guess it is stripped in between. 

[kdas@d80 lib]$ eu-readelf -s libexiv2.so.5 | grep _ZNK5Exiv29Exifdatum6typeIdEv
 1403: 00056850     23 FUNC    LOCAL  HIDDEN        11 _ZNK5Exiv29Exifdatum6typeIdEv

^^ the above is on a locally compiled exiv2. As I can see it is hidden function , I  guess it is not supposed to be used outside. Though I can not any reference to it in pyexiv2 code.

Comment 4 Kevin Kofler 2009-04-17 04:01:40 UTC
I think the problem is that there were some API changes in exiv2 and the symbol is now private, i.e. no longer exported. So it shows up either as hidden/local or not at all.

I guess a quick hack (but most likely not the right solution) to get pyexiv2 to work would be to patch libexiv2 to export that symbol.

Comment 5 Kevin Kofler 2009-04-17 04:03:47 UTC
And has anybody checked whether the 0.1.3 release fixes it?

Comment 6 kushaldas@gmail.com 2009-04-17 04:32:20 UTC
(In reply to comment #5)
> And has anybody checked whether the 0.1.3 release fixes it?  

I tried, it is still failing in 0.1.3 :(

Comment 7 Matěj Cepl 2009-04-17 13:03:23 UTC
(In reply to comment #5)
> And has anybody checked whether the 0.1.3 release fixes it?  

The bug being blocked by this (bug 494419) is about upgrade to 0.1.3 of pyexiv2.

Comment 8 Matěj Cepl 2009-04-17 13:04:32 UTC
Moreover, there is my (untagged, so it will get garbage-collected eventually) build of pyexiv2 0.1.3 at http://koji.fedoraproject.org/koji/taskinfo?taskID=1302917

Comment 9 Rex Dieter 2009-04-17 18:50:22 UTC
0.1.3 has the same problem.

Notify upstream, in the meantime, I'll see about (temporarily) making the symbol non-private.

Comment 10 Rex Dieter 2009-04-17 18:55:05 UTC
I'm looking closer @ exiv2, and my reading of exif.hpp seems to be that this symbol should be public too.  sigh, double-checking exiv2 code...

Comment 11 Rex Dieter 2009-04-17 19:13:34 UTC
methinks visibility is indeed fubar in exiv2.  Hardly any symbols are marked exported, and certainly none of the typeId methods.  I'll ping upstream.

Comment 12 Rex Dieter 2009-04-17 19:28:14 UTC
more bz spam: :)

OK, my uneducated eye thinks it has something to do with -fvisibility-inlines-hidden , since the awol methods are indeed inlines in .hpp files.

Not sure how best to handle this.

diable visibility altogether?
hack out use of -fvisibility-inlines-hidden?

Comment 13 Rex Dieter 2009-04-17 19:54:59 UTC
going with the latter, 

* Fri Apr 17 2009 Rex Dieter <rdieter> - 0.18.1-1
- exiv2-0.18.1
- drop -fvisibility-inlines-hidden (#496050)

Comment 14 Rex Dieter 2009-04-17 20:08:39 UTC
upstream bug report,

Comment 15 Rex Dieter 2009-04-17 20:12:36 UTC
please test:

Comment 16 kushaldas@gmail.com 2009-04-18 06:06:45 UTC
Works for me, I can now import pyexiv2 and use it :)

Comment 17 Rex Dieter 2009-04-29 16:29:11 UTC

I've confirmed from discussing this with exiv2 upstream that the necessary symbols *are* properly included in libexiv2, per comment #3, but are still marked as hidden (I'm still unsure of those ramifications).

but... turns out that building pyexiv2 without pyexiv2-packager.patch makes it work.  I narrowed it down to: building with -O0 works, anything higher fails as described here.

So, if you don't mind, please ping upstream pyexiv2 to try to help find out why varying optimization levels are harming things here.  I'll continue to do the same on the exiv2 side of things.

Regardless, I'll continue to keep the partially hacked exiv2 that works now, until we find a better solution.

Comment 18 Rex Dieter 2009-04-29 16:29:58 UTC
fyi, exiv2 upstream discussion is ongoing at

Comment 19 Matěj Cepl 2009-04-30 15:50:11 UTC
What do you think about this:

Index: pyexiv2.spec
RCS file: /cvs/extras/rpms/pyexiv2/devel/pyexiv2.spec,v
retrieving revision 1.10
diff -u -3 -p -r1.10 pyexiv2.spec
--- pyexiv2.spec	23 Apr 2009 10:51:00 -0000	1.10
+++ pyexiv2.spec	30 Apr 2009 15:49:18 -0000
@@ -33,17 +33,16 @@ embedded in image files (JPEG, TIFF, ...
 %patch1 -p1 -b .packager
-# Remove CFLAGS=... for noarch packages (unneeded)
-#CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build
-export CXXFLAGS="%{optflags}"
-export LDFLAGS="%{optflags}"
+export CFLAGS="$(echo %{optflags}|sed -e 's/O2/O0/')"
+export CXXFLAGS="$(%{optflags}|sed -e 's/O2/O0/')"
+export LDFLAGS="$(%{optflags}|sed -e 's/O2/O0/')"
-#%{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT
-export CXXFLAGS="%{optflags}"
-export LDFLAGS="%{optflags}"
+export CFLAGS="$(echo %{optflags}|sed -e 's/O2/O0/')"
+export CXXFLAGS="$(%{optflags}|sed -e 's/O2/O0/')"
+export LDFLAGS="$(%{optflags}|sed -e 's/O2/O0/')"
 scons DESTDIR=$RPM_BUILD_ROOT install

Comment 20 Rex Dieter 2009-04-30 16:49:33 UTC
that may be a good temporary solution.  

Btw, exiv2 upstream was able to reproduce the problem using optimized pyexiv2 builds too.  Does pyexiv2 upstream know about this issue yet? (hint hint... :) )

Comment 21 Rex Dieter 2009-04-30 16:51:08 UTC
I'm also ok with keeping the exiv2 temporary solution of not using -fvisibility-inlines-hidden too.  exiv2 upstream was going to be moving away from using public inlined methods too, partly to avoid this kind of problem too.

Comment 22 Matěj Cepl 2009-05-02 08:37:55 UTC
(In reply to comment #20)
> that may be a good temporary solution.  
> Btw, exiv2 upstream was able to reproduce the problem using optimized pyexiv2
> builds too.  Does pyexiv2 upstream know about this issue yet? (hint hint... :)
> )  

done https://bugs.launchpad.net/pyexiv2/+bug/370751

Comment 23 Matěj Cepl 2009-05-02 08:39:01 UTC
I think we have not much to do here in Fedora with this. So, closing bug as UPSTREAM and let's see what upstreams decide.

Comment 24 Rex Dieter 2009-08-07 16:56:03 UTC
Rats, I thought upstream had resolved this, and botched my own local test for it, so it came back in the exiv2-0.18.2-1.fc11 update.

Comment 25 Fedora Update System 2009-08-07 17:03:54 UTC
exiv2-0.18.2-2.fc11 has been submitted as an update for Fedora 11.

Comment 26 Oron Peled 2009-08-08 17:14:39 UTC
Hmmm... some observations.

* Just tested exiv2-0.18.2-2.fc11 and it works around the problem.
  The import succeeds with it and fails with original 0.18.2-1.f11

* I think that the different behavior with -O0 is related to the
  fact that g++ does *NOT* inline without optimization turned on.
  (look for -fno-default-inline in gcc info docs)

* As a result, with -O0 we simply force g++ to compile a copy
  of the function into the object file (no inline) and therefore
  the -fvisibility-inlines-hidden does not affect it anymore.
  Problem "solved" ;-)

* It looks like an upstream bug to me:
  - If Exifdatum::typeId() is an officially exported API, they should
    have marked it like their other methods with EXIV2API macro
  - This macro is expanded to EXV_EXPORT in the exv_conf.h header
  - The EXV_EXPORT sets the visibility attribute to "default"
    in the same header. This would make it visible again.

Comment 27 Oron Peled 2009-08-08 17:46:11 UTC
Just confirmed:
 * Added EXIV2API before Exifdatum::typeId() in exif.hpp and rebuilt an RPM.
 * Tried to import pyexiv2 from python (after installing the rogue RPM).
 * It now failes on Iptcdatum::typeId()
 * Rinse, wash, repeat, ...

Comment 28 Fedora Update System 2009-08-08 19:23:40 UTC
exiv2-0.18.2-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.