yes, working on upgrade

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

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.

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.

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.

And has anybody checked whether the 0.1.3 release fixes it?

(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 :(

(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.

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

0.1.3 has the same problem.

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

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...

methinks visibility is indeed fubar in exiv2.  Hardly any symbols are marked exported, and certainly none of the typeId methods.  I'll ping upstream.

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?

going with the latter, 

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

upstream bug report,
http://dev.exiv2.org/issues/show/627

please test:
http://koji.fedoraproject.org/koji/buildinfo?buildID=98405

Works for me, I can now import pyexiv2 and use it :)

Re-opening... 

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.

fyi, exiv2 upstream discussion is ongoing at
http://dev.exiv2.org/issues/show/627

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
 
 %build
-# 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/')"
 scons
 
 %install
 rm -rf $RPM_BUILD_ROOT
-#%{__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
 
 %clean

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... :) )

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.

(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

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.

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.

exiv2-0.18.2-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/exiv2-0.18.2-2.fc11

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.

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, ...

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.