Bug 165729 - OpenEXR: drop Requires: zlib-devel, unresolved symbols in shared libs
OpenEXR: drop Requires: zlib-devel, unresolved symbols in shared libs
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: OpenEXR (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ignacio Vazquez-Abrams
Fedora Extras Quality Assurance
: Patch
Depends On: 165916
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-11 12:28 EDT by Rex Dieter
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-19 08:03:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for specfile (750 bytes, patch)
2006-02-09 13:30 EST, Eric Bourque
no flags Details | Diff
fix for unresolved symbols in shared libraries (3.04 KB, patch)
2006-02-09 15:40 EST, Rex Dieter
no flags Details | Diff
updated to use LIBADD, Makefile.am files only (1.82 KB, patch)
2006-02-10 08:17 EST, Rex Dieter
no flags Details | Diff

  None (edit)
Description Rex Dieter 2005-08-11 12:28:43 EDT
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.
Comment 1 Michael Schwendt 2005-08-11 12:56:37 EDT
pkgconfig file does -lz, so dependency is correct.
Comment 2 Rex Dieter 2005-08-11 13:02:57 EDT
Then patch the pkgconfig file, it's wrong (just like how .la archives include
everything under the sun too).
Comment 3 Ignacio Vazquez-Abrams 2005-08-14 07:15:04 EDT
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).
Comment 4 Eric Bourque 2006-02-09 13:30:44 EST
Created attachment 124446 [details]
patch for specfile
Comment 5 Eric Bourque 2006-02-09 13:32:51 EST
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.
Comment 6 Rex Dieter 2006-02-09 14:16:38 EST
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?
Comment 7 Eric Bourque 2006-02-09 14:30:11 EST
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.
Comment 8 Rex Dieter 2006-02-09 14:39:12 EST
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.
Comment 9 Rex Dieter 2006-02-09 15:40:42 EST
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).
Comment 10 Eric Bourque 2006-02-09 17:22:17 EST
Nice. I would recommend only patching .am files, and calling bootstrap in the
build scriptlet. This patch should also be sent upstream.
Comment 11 Rex Dieter 2006-02-10 08:17:51 EST
Created attachment 124487 [details]
updated to use LIBADD, Makefile.am files only

Submitted upstream to openexr-devel mailing list.
Comment 12 Rex Dieter 2006-02-15 15:35:08 EST
Ignacio, I can import and apply the patch in cvs (if you don't mind).
Comment 13 Ignacio Vazquez-Abrams 2006-02-15 16:40:25 EST
Is the latest patch the only thing that needs to be applied? autotools will have
to be called afterwards, correct?
Comment 14 Eric Bourque 2006-02-15 16:49:56 EST
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}
Comment 15 Rex Dieter 2006-02-15 21:29:01 EST
FYI, you really should call autotools/bootstrap after applying patches in the
%prep section, not %build.
Comment 16 Eric Bourque 2006-02-16 00:58:47 EST
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.
Comment 17 Rex Dieter 2006-02-16 07:54:15 EST
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.
Comment 18 Ignacio Vazquez-Abrams 2006-02-18 02:44:21 EST
So then do I still need the original patch for removing -lz for the .pc file?
Comment 19 Rex Dieter 2006-02-18 09:43:57 EST
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).
Comment 20 Ignacio Vazquez-Abrams 2006-02-19 01:13:18 EST
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
Comment 21 Rex Dieter 2006-02-19 07:38:35 EST
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)
Comment 22 Ignacio Vazquez-Abrams 2006-02-19 08:03:42 EST
Well, I requeued it and it succeeded. Closing.
Comment 23 Ignacio Vazquez-Abrams 2006-03-31 17:24:27 EST
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
Comment 24 Rex Dieter 2006-04-01 13:10:24 EST
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.

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