OpenEXR-1.2.2-3: -devel subpkg doesn't need the Requires: zlib-devel (there's no reference to zlib headers in OpenEXR's headers). While you're at it, you could simplify things and reduce -devel's size by adding --disable-static to %configure to not include the static lib.
pkgconfig file does -lz, so dependency is correct.
Then patch the pkgconfig file, it's wrong (just like how .la archives include everything under the sun too).
It seems that OpenEXR doesn't build with gcc 4.0.1 even though it works with 4.0.0 (with a small packaging error caught by the new rpm).
Created attachment 124446 [details] patch for specfile
The claim above about OpenEXR not needing zlib isn't true. It doesn't need zlib-devel though. I have created a patch for the spec file which is attached to this bug report.
Manually adding Requires: zlib is wrong, it should pick up the shared libary dependancy automatically. What made you think your patch is adding the manual dependancy is necessary?
By putting zlib in manually, it is not tied to any particular version, i.e., it is the symbol which is used. This doesn't happen automatically, unless rpm has changed a lot recently and I'm not aware of it. The most important part of the patch however, is that pkg-config *does* need to have -lz in the libs file as distributed in the original source. Otherwise packages which use pkg-config --libs OpenEXR to specify the link libraries will have unresolved symbols during the link phase.
Wrong fix. Problem is the shared library has undefined symbols: $ldd -r /usr/lib/libIlmImf.so undefined symbol: uncompress (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex13throwErrnoExcERKSs (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExcD2Ev (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExc6assignERSt18basic_stringstreamIcSt11char_traitsIcESaIcEE (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExcC2ERSt18basic_stringstreamIcSt11char_traitsIcESaIcEE (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExcC2EPKc (/usr/lib/libIlmImf.so) undefined symbol: _ZN4half7convertEi (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExcC1EPKc (/usr/lib/libIlmImf.so) undefined symbol: compress (/usr/lib/libIlmImf.so) undefined symbol: _ZN3Iex7BaseExcD1Ev (/usr/lib/libIlmImf.so) undefined symbol: _ZTIN3Iex7BaseExcE (/usr/lib/libIlmImf.so) undefined symbol: _ZN4half5_eLutE (/usr/lib/libIlmImf.so) undefined symbol: _ZN4half8_toFloatE (/usr/lib/libIlmImf.so) undefined symbol: _ZNK3Iex7BaseExc4whatEv (/usr/lib/libIlmImf.so) $ldd -r /usr/lib/libImath.so ... undefined symbol: _ZN3Iex7BaseExcD2Ev (/usr/lib/libImath.so) undefined symbol: _ZN3Iex7BaseExcC2EPKc (/usr/lib/libImath.so) undefined symbol: _ZTIN3Iex7BaseExcE (/usr/lib/libImath.so) undefined symbol: _ZNK3Iex7BaseExc4whatEv (/usr/lib/libImath.so) So, looks like we have more work to do.
Created attachment 124453 [details] fix for unresolved symbols in shared libraries Includes modifcations to both Makefile.in, Makefile.am files. the Makefile.am bits could probably be omitted (but only if you never plan on re-automake'ing things).
Nice. I would recommend only patching .am files, and calling bootstrap in the build scriptlet. This patch should also be sent upstream.
Created attachment 124487 [details] updated to use LIBADD, Makefile.am files only Submitted upstream to openexr-devel mailing list.
Ignacio, I can import and apply the patch in cvs (if you don't mind).
Is the latest patch the only thing that needs to be applied? autotools will have to be called afterwards, correct?
There is already a bootstrap script, so you can just call that in the build section: %prep %setup -q %patch -p1 -b .makefile %patch1 -p1 -b .forwardfriend %build ./bootstrap %configure --disable-static make %{?_smp_mflags}
FYI, you really should call autotools/bootstrap after applying patches in the %prep section, not %build.
By that logic, you should also call configure there as well. bootstrap is 'building' the Makefile.in's and configure is building the Makefiles. Both could be in either section as long as the order is respected, but the convention I've seen has been as I included above.
autotools/boostrap is not part of a normal build process (or at least shouldn't be), and is (usually) associated directly with patching, which is done in %prep. This is the convention I've usually seen, and what I personally always follow. YMMV.
So then do I still need the original patch for removing -lz for the .pc file?
Yes, you should still apply the original pkgconfig patch. The new patch is just to fix other side-effects (sorry for not making that clear).
Okay, here's an interesting one. The x86_64 .la file doesn't look different from the i386 one other than s/lib/lib64/. Both i386 and ppc built. http://buildsys.fedoraproject.org/logs/fedora-development-extras/4902-OpenEXR-1.2.2-7.fc5/x86_64/build.log
A wierd one alright: libtool: link: `/usr/lib64/libfreetype.la' is not a valid libtool archive I can tell you that OpenEXR built fine for me on x86_64 in mock (for fc4 and rhel4) using the patches here. May be worth taking to the mailing list(s), to see if anyone else might have a better idea what's going on. (Could simply be rawhide wierdness)
Well, I requeued it and it succeeded. Closing.
So I *finally* got a response from upstream about this. Here's what they had to say: "OpenEXR does need zlib in order to work. Zlib is required for the ZIP and PXR24 compression schemes." http://savannah.nongnu.org/bugs/?func=detailitem&item_id=14112
Of course OpenEXR needs zlib at *runtime*. Their response in that regard seems like they didn't even read the post or understand its context. However, in fairness, the zlib reference *is* required if linking statically, so upstream may well be hesitant to remove it.