Bug 112398
Summary: | ImageMagick-c++ and ImageMagick-perl packages missing in RHEL. 3 ES | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Joseph Tate <jtate> |
Component: | ImageMagick | Assignee: | Matthias Clasen <mclasen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | herrold, managed, nobody+pnasrat, redhat-mail, terjekv |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-26 20:31:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joseph Tate
2003-12-18 23:20:38 UTC
You can compile the SRPM by running: rpm -e ImageMagick && /sbin/up2date -u --src ImageMagick The only issue is you have to actually compile ImageMagick-devel and install that first, then recompile ImageMagick-perl. If you don't do so you get a relocation error, since ImageMagick-perl did not compile against the libMagick.so installed by ImageMagick-devel. Kind of weird, but nice to note. We can confirm the regression of ImageMagick support in RHEL3. In addition to missing: ImageMagick-c++ ImageMagick-perl RHEL3 is also missing: ImageMagick-devel ImageMagick-c++-devel In addition to failing to support ImageMagick-perl, it fails to provide the /usr/lib/libMagick.so.5 symlink to the current /usr/lib/libMagick.so.5* library. Lack of ImageMagick support in RHEL3 has put a stop on our migrating from RH9 to RHEL3. Yes, we could go out and build it all ourselves, however our decision to go to RHEL instead of Fedora was to run our production servers on a supported platform. We have a number of apps that link with /usr/lib/libMagick.so.5 or use ImageMagick via the Perl interface. Going the 'unsupported' route of rolling our own ImageMagick is not an option that we want to take on our production systems. We are hoping that Red Hat will fix this problem and release a ImageMagick-devel, ImageMagick-c++, ImageMagick-c++-devel, and ImageMagick-perl package set soon! BTW: We received an EMail message from someone who said:
> You (redhat-mail) said:
> > ... Yes, we could go out and build it all ourselves, however ...
> I am winning to build it, but I do not know how. You seem to imply that
> you do know how to build it from the source RPM. We tried what was
> suggested but it didn't install stuff. Do you know how?
Yes. Here is how someone who is willing to "install an unsupported
ImageMagick" might do it using the source RPM (sans any typos I might
introduce :-)):
1) clean out and current ImageMagick RPMs
rpm -e --nodeps ImageMagick ImageMagick-c+ ImageMagick-perl
rpm -e --nodeps ImageMagick-devel ImageMagick-c++-devel
2) download the source RPM
up2date -u --src ImageMagick
cd /var/spool/up2date
echo you should see the src RPM
ls -l ImageMagick-*.src.rpm
3) rebuild the rpm set from the src RPM
cd /var/spool/up2date
rpmbuild --rebuild -v ImageMagick-*.src.rpm
echo If all goes well, you should see some new RPMs here
ls -s $( find /usr/src/redhat/RPMS -type f -name 'ImageMagick-*.rpm' )
4) pre-test the newly generated RPMs
cd /usr/src/redhat/RPMS
rpm --test -ivh $( find . -type f -name 'ImageMagick-*.rpm' )
5) If all is well, then install those new RPMs
echo Our habbit is to keep the RPMs we use in one place
echo So first we move the new RPMs over to /var/spool/up2date
cd /usr/src/redhat/RPMS
mv -f $( find . -type f -name 'ImageMagick-*.rpm' ) /var/spool/up2date
echo next, we install the non-src RPMs from the up2date area
cd /var/spool/up2date
rpm -ivh $( find . -type f -name 'ImageMagick-*.rpm' \
! -name '*.src.rpm' )
NOTE: On RHEL3, that should do almost to everything. The rpm spec file does
not generate the libMagick.so.5 symlinks. You will need to make them yourself.
6) Generate the missing symlinks:
cd /usr/lib
ln -s libMagick.so /usr/lib/libMagick.so.5
ln -s libMagick++.so /usr/lib/libMagick++.so.5
But as I said before, we are hoping that Red Hat will come out and fully
support the complete ImageMagick RPM set sometime ...
BTW to Red Hat:
You might want to modify the RPM so it will generate those missing
symlinks as noted in step 6 above.
Typo correction: In step 1) the line: rpm -e --nodeps ImageMagick ImageMagick-c+ ImageMagick-perl should read: rpm -e --nodeps ImageMagick ImageMagick-c++ ImageMagick-perl I got bitten by comment #1 Building ImageMagick-perl succesfully against libMagick requires ImageMagick-devel on build host meaning a two pass build. Rebuilding on FC 1 and on RHEL ES 3 without results in no link against libMagick.so in Magick.so. Surely this should build using the libs in ../magick/.libs for a one pass install. I assume beehive must have Magick recipe to do this - is this correct? Is anyone from Red Hat following this? This bug was not fixed in RHEL3 Beta 3. Is there a release where this problem will be fixed? right, this is just dandy. we've just migrated to RHEL and well... nommo:/# rpm -qi ImageMagick | tail -4 ImageMagick is one of your choices if you need a program to manipulate and dis play images. If you want to develop your own applications which use ImageMagick code or APIs, you need to install ImageMagick-devel as well. nommo:/# up2date -i ImageMagick-devel | tail -2 The following packages you requested were not found: ImageMagick-devel sigh. is anyone from Red Hat looking into this? The next RHEL update will include ImageMagick-devel, Image-Magick-c++ and Image-Magick-c++-devel. We didn't get ImageMagick-perl added in time, but it will hopefully occur in the following update. How do you selectively build subpackages in a spec? When I try to follow the above listed instructions, the build bombs and no rpms are generated. I've tried disabling lines in the spec and building from that, but I'm not making much progress. I'm not sure which instructions you were following. Personally I'd build all the subpackages, not just a few. Follow comment #3 (with the typo fix as noted in comment #4). You may run into the problem noted in comment #5. If you do, install what was successfully built and then repeat the process ... this time without the pre-removal step 1. This appears to be in U4, so I'm closing this issue. |