Bug 112398 - ImageMagick-c++ and ImageMagick-perl packages missing in RHEL. 3 ES
ImageMagick-c++ and ImageMagick-perl packages missing in RHEL. 3 ES
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ImageMagick (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-12-18 18:20 EST by Joseph Tate
Modified: 2007-11-30 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-26 16:31:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Tate 2003-12-18 18:20:38 EST
Description of problem:
The only ImageMagick package provided in all of the channels for ES is
ImageMagick-5.5.6.  Heaven forbid if anyone should want to embed
ImageMagick into an application, or use it from within perl.

Version-Release number of selected component (if applicable):
Comment 1 Samuel Stringham 2004-02-25 12:00:47 EST
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.
Comment 2 Landon Curt Noll 2004-02-29 05:59:21 EST
We can confirm the regression of ImageMagick support in RHEL3. 
In addition to missing: 
RHEL3 is also missing: 
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! 
Comment 3 Landon Curt Noll 2004-02-29 09:17:32 EST
BTW: We received an EMail message from someone who said: 
> You (redhat-mail@asthe.com) 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. 
Comment 4 Landon Curt Noll 2004-02-29 09:21:34 EST
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 
Comment 5 Paul Nasrat 2004-03-09 08:16:42 EST
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?
Comment 6 Anchor Systems Managed Hosting 2004-04-01 03:12:42 EST
Is anyone from Red Hat following this?
Comment 7 Landon Curt Noll 2004-04-22 02:39:16 EDT
This bug was not fixed in RHEL3 Beta 3. 
Is there a release where this problem will be fixed? 
Comment 8 Terje Kvernes 2004-05-05 13:29:44 EDT
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:

sigh.  is anyone from Red Hat looking into this?
Comment 9 Jonathan Blandford 2004-05-07 12:22:37 EDT
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.
Comment 10 Michael Cook 2004-05-09 09:23:30 EDT
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.
Comment 11 Landon Curt Noll 2004-05-09 09:37:22 EDT
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. 
Comment 12 Suzanne Hillman 2005-04-26 16:31:08 EDT
This appears to be in U4, so I'm closing this issue.

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