Bug 203975 - Undefined symbol: InitializeMagick in
Undefined symbol: InitializeMagick in
Product: Fedora
Classification: Fedora
Component: ImageMagick (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Norm Murray
Mike McLean
: 203966 203977 204201 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-08-24 15:19 EDT by Stuart Rauh
Modified: 2007-11-30 17:11 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-28 01:09:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rebuild log of fc5 ImageMagick by normal rpmbuild (317.82 KB, text/plain)
2006-09-21 03:54 EDT, Mamoru TASAKA
no flags Details
rebuild log of fc5 ImageMagick IN MOCK (351.26 KB, text/plain)
2006-09-21 04:01 EDT, Mamoru TASAKA
no flags Details
patch to link against libMagick.so.9 (1.23 KB, patch)
2006-09-21 07:02 EDT, Mamoru TASAKA
no flags Details | Diff

  None (edit)
Description Stuart Rauh 2006-08-24 15:19:03 EDT
Description of problem:
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-
linux-thread-multi/auto/Image/Magick/Magick.so: undefined symbol: 

Version-Release number of selected component (if applicable):
ImageMagick -, ImageMagick-Perl -
4.1.1.fc5.4.i386 fail with the above error.

Backing down to version works fine.

How reproducible:
Every time I run a perl script that manipulates an image.  These scripts used 
to work fine.
Comment 1 Patrick Mansfield 2006-08-25 00:41:32 EDT
This is a serious bug since the update was for a security fix.

So you can down rev and run with the security bug, or run with the ones that
don't work at all :-(

Stuart - you opened two bugs, you should close the other one, bug 203977.
Comment 2 Stuart Rauh 2006-08-25 10:38:30 EDT
*** Bug 203977 has been marked as a duplicate of this bug. ***
Comment 3 Ed Hill 2006-09-04 19:44:08 EDT
Hi folks, any progres here?  This bug breaks a bunch of scripts and
the older version is disappearing from the repos...
Comment 4 Ed Hill 2006-09-04 20:48:49 EDT
Just for reference, heres a one-liner that triggers the problem:

  perl -e ' use Image::Magick;'
Comment 5 Norm Murray 2006-09-05 23:25:41 EDT
*** Bug 203966 has been marked as a duplicate of this bug. ***
Comment 6 Norm Murray 2006-09-05 23:25:59 EDT
*** Bug 204201 has been marked as a duplicate of this bug. ***
Comment 7 Norm Murray 2006-09-05 23:29:16 EDT
I've got the problem reproduced and have tracked down that it seems to be a
missing dependency where
in ImageMagick- has not picked up the dependency on

Working on figuring out why that has happened now. 
Comment 8 Toby Ovod-Everett 2006-09-06 10:51:11 EDT
Just in case someone's reading this thread and doesn't know what to do, here's 
what I've done/am doing:

* Check what ImageMagick modules are on your machines:
  rpm -qa --queryformat='%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep 

  I get the list:

* Download the older updates from 
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/ (i386 or 
x86_64 as appropriate).  You want the ones dated around May 25.  You should 
have one for each of the modules installed on your machine.

* Uninstall the existing ImageMagick stuff - rpm -e followed by each of the 
above.  For instance:
  rpm -e ImageMagick-perl- ImageMagick-
4.2.1.fc5.4.x86_64 ImageMagick-

* Install the newly downloaded RPMs (easiest to do all at once - you can do 
something like:
  rpm -i ImageMagick**

* Until this issue is resolved, exclude ImageMagick from yum updates like so:
  yum update --exclude='ImageMagick*'
Comment 9 JLapham 2006-09-07 17:03:02 EDT
Could this bug get the severity raised to *urgent* please?  (or *regression*,
but that doesn't seem to be an option in the popup menu)

Could this bug get the priority raised to *high* please?

Comment 10 Ed Hill 2006-09-07 19:55:53 EDT
Hi folks, I've upped the priority/severity since the perl functionality 
here is completely borked -- it completely breaks a lot of scripts.

Also, I'd like to point out that you can download the older RPMs:


as described in comment #8 above and then install them immediately 
(without first removing them and any dependencies) using the rpm 
"--oldpackage" option.  This makes it just a little easier to get 
rid of the broken .4 RPMs and replace with the working (but apparently
with security flaw-ed?) .3 ones.
Comment 11 Toby Ovod-Everett 2006-09-08 01:03:02 EDT
According to https://rhn.redhat.com/errata/RHSA-2006-0633.html, the security 
flaw is exploitable only if the attacker can convince you (or your code) to use 
ImageMagick to decode "XCF, SGI, and Sun bitmap graphic files."  If you do not 
allow untrusted individuals to upload or process image files, my understanding 
is that the risk is mitigated.  I don't know how ImageMagick handles image 
decoding, so it is conceivable that allowing untrusted individuals to upload 
(for instance) JPG files might allow them to upload a malicious XCF file that 
had a .jpg extension, but ImageMagick might still process it as an XCF file 
because the first few bytes look like an XCF file, and thus the vulnerability 
might be exploitable.
Comment 12 Andy Bakun 2006-09-12 03:51:37 EDT
ldd and objdump show that Magick.so is not linked against libMagick.so, *none*
of the ImageMagick symbols are defined.

A quick fix, if you really need the security fixes (and who doesn't need
security fixes?) is to create a new Magick.so that is linked against it:

  cd `find /usr/lib/perl5 -name "Magick.so" | xargs dirname`
  mv Magick.so Magick-0.so
  ld -shared -o Magick.so `pwd`/Magick-0.so /usr/lib/libMagick.so.9

Unfortunately, you can't just use -lMagick because for some reason
/usr/lib/libMagick.so doesn't exist, just /usr/lib/libMagick.so.9.

The resultant Magick.so is successfully loaded by perl and reads and generates
images in scripts that worked fine with the version.  I have
not tested it extensively, nor have I tested it against the buffer/integer
overflow problems that .4 is supposed to fix.

This is only a stop-gap measure -- this really needs to be properly fixed.
Comment 13 Thomas Zehetbauer 2006-09-12 08:33:48 EDT
I have had the same problem on x86_64; solved it by rebuilding the update from
the source package; the same solution worked on a i386 system; I guess the
update was built on a machine that has some inofficial updates installed.
Comment 14 Max Spevack 2006-09-18 14:05:16 EDT

Any updates from you as per comment #7.  There's a lot of chatter about this
bug.  Between it and all of its duplicates, it's kind of crazy that we haven't
managed to fix it yet.

What's blocking us from getting an update here?  This is related to a security
fix, right?  It's kind of embarassing that it's taking this long.

Set to block FC6.  If this really is a security issue, I encourage wwoods not to
certify FC6 unless it has fixed code.  We shouldn't ship with a known security
Comment 15 JLapham 2006-09-20 08:55:23 EDT
Just to explain the situation a bit Max.  The last working packages of
ImageMagick ( have the security issue.  The "updated"
package that Matthias Clasen made on August 23 (


...do not have the security issue, but the packages simply don't work.  You may
already understand that, if so I apologize.  

To wit, your last sentence in comment #14 should read "We shouldn't ship with
non-functioning software".
Comment 16 Thomas Zehetbauer 2006-09-20 09:14:19 EDT
Has anyone here tried my solution from comment #13 yet?

Just "rpmbuild --rebuild" the SRPM from
and install the resulting packages with "rpm --install --force"

This worked on both (x86_64 and i386) of my fedory systems. If this turns out to
work, everything the fedora people have to do is to bump up the version number
and rebuild the packages on a CLEAN FC5 installation.

Comment 17 Mamoru TASAKA 2006-09-21 03:44:07 EDT
(In reply to comment #16)
> Has anyone here tried my solution from comment #13 yet?
> Just "rpmbuild --rebuild" the SRPM from
> and install the resulting packages with "rpm --install --force"
> This worked on both (x86_64 and i386) of my fedory systems. If this turns out to
> work, everything the fedora people have to do is to bump up the version number
> and rebuild the packages on a CLEAN FC5 installation.
> Tom

I tried to rebuild ImageMagick- with just release number
incremented, and the answer was _NO_ . To be more precise, rebuilding 
this srpm by normal rpmbuild seems okay, however, rebuilding this srpm
IN MOCK leaves this problem unsolved.

This means that the compilation of ImageMagick- needs
ImageMagick itself pre-installed.

Note: I don't see any problem in rawhide ImageMagick rpms. Now I am trying
to rebuild rawhide ImageMagick (this version is 6.2.8) in FC5 mock envorinment 
to see if this problem disappears.

Comment 18 Mamoru TASAKA 2006-09-21 03:54:13 EDT
Created attachment 136831 [details]
rebuild log of fc5 ImageMagick by normal rpmbuild

rebuild log of ImageMagick- by normal
ImageMagick (under the envoronment that ImageMagick itself
is already installed).
Comment 19 Mamoru TASAKA 2006-09-21 04:01:07 EDT
Created attachment 136833 [details]
rebuild log of fc5 ImageMagick IN MOCK

Rebuild log of ImageMagick- in fc5 mock environment.

You can see the important difference:

@@ -1363,14 +1761,15 @@
  /usr/bin/install -c 'magick/Magick-config'
  /usr/bin/install -c 'Magick++/bin/Magick++-config'
  /usr/bin/install -c 'wand/Wand-config'
-cd PerlMagick && /usr/bin/perl Makefile.PL INSTALLDIRS=vendor	CC='gcc
/.libs' LDDLFLAGS='-shared
+cd PerlMagick && /usr/bin/perl Makefile.PL INSTALLDIRS=vendor	CC='gcc
 LDDLFLAGS='-shared -L/builddir/build/BUILD/ImageMagick-6.2.5/magick/.libs'
 Checking if your kit is complete...
 Looks good
+Note (probably harmless): No library found for -lMagick
 Writing Makefile for Image::Magick
 ( cd PerlMagick && make CC='gcc' && \
 make CC='gcc' install && \
 make clean && rm -f  Makefile.old )
-make[2]: Entering directory
+make[2]: Entering directory
 cp Magick.pm blib/lib/Image/Magick.pm
 AutoSplitting blib/lib/Image/Magick.pm (blib/lib/auto/Image/Magick)
 /usr/bin/perl /usr/lib/perl5/5.8.8/ExtUtils/xsubpp  -typemap
/usr/lib/perl5/5.8.8/ExtUtils/typemap  Magick.xs > Magick.xsc && 
mv Magick.xsc Magick.c
@@ -1475,15 +1874,15 @@
 Running Mkbootstrap for Image::Magick ()
 chmod 644 Magick.bs
 rm -f blib/arch/auto/Image/Magick/Magick.so
-gcc  -shared -L/home/tasaka1/rpmbuild/BUILD/ImageMagick-6.2.5/magick/.libs
Magick.o  -o blib/arch/auto/Image/Magick/Magick.so 
-   -L/usr/lib -lMagick -lfreetype -lz -L/usr/lib -ltiff -lfreetype -ljpeg -lgs
-lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lpthrea
d -lm -lpthread 	 \
+gcc  -shared -L/builddir/build/BUILD/ImageMagick-6.2.5/magick/.libs Magick.o 
-o blib/arch/auto/Image/Magick/Magick.so 
+   -L/usr/lib -lfreetype -lz -L/usr/lib -ltiff -lfreetype -ljpeg -lgs -lXext
-lSM -lICE -lX11 -lXt -lbz2 -lz -lpthread -lm -lp
thread	 \
Comment 20 Mamoru TASAKA 2006-09-21 07:02:47 EDT
Created attachment 136845 [details]
patch to link against libMagick.so.9

Backported from ImageMagick-6.2.8

This patch seems to work for me.
Comment 21 Mamoru TASAKA 2006-09-21 07:09:46 EDT
Removing dependency for FC6Blocker. Rawhide ImageMagick 
(ImageMagick- does not have this problem.
Comment 22 Fedora Update System 2006-09-22 15:42:02 EDT
ImageMagick- has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 23 Mamoru TASAKA 2006-09-23 02:30:57 EDT
Well, ImageMagick-perl- seems okay for me.

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