Red Hat Bugzilla – Bug 165729
OpenEXR: drop Requires: zlib-devel, unresolved symbols in shared libs
Last modified: 2007-11-30 17:11:11 EST
-devel subpkg doesn't need the
(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
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.
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.
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: _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
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:
%patch -p1 -b .makefile
%patch1 -p1 -b .forwardfriend
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.
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.
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
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.