Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 121142 - imagemagick- links perl library against external
Summary: imagemagick- links perl library against external
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Karol Wojtaszek (RETIRED)
: 121434 121509 137798 140374 141658 143157 (view as bug list)
Depends on:
Reported: 2006-02-01 01:04 UTC by Nico Erfurth
Modified: 2006-09-20 19:22 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---

the patch for the current ebuild (imagemagick-ebuild.patch,559 bytes, patch)
2006-07-19 08:29 UTC, Sven
Details | Diff
the patch for PerlMagick/ (imagemagick-perl.patch,951 bytes, patch)
2006-07-19 08:29 UTC, Sven
Details | Diff
patch for the ebuild (imagemagick-ebuild.patch,908 bytes, patch)
2006-07-19 10:55 UTC, Sven
Details | Diff
patch for PerlMagick/ and PerlMagick/ (imagemagick-perl.patch,1.46 KB, patch)
2006-07-19 10:55 UTC, Sven
Details | Diff
new patch for current imagemagick- (ebuild.patch,1.31 KB, patch)
2006-09-05 09:23 UTC, Sven
Details | Diff
new patch for PerlMagick/ (imagemagick-perl.patch,951 bytes, patch)
2006-09-05 09:24 UTC, Sven
Details | Diff
Fix for the case, that imagemagick is not installed already (imagemagick-perl.patch,1.64 KB, patch)
2006-09-18 16:22 UTC, Sven
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Erfurth 2006-02-01 01:04:51 UTC
Yesterday I built imagemagick- and the file from the perl extension was linked against instead of so.9, provided by the new ebuild. Most probably it just linked against the file in /usr/lib instead of the one in its own working directory.

Rebuilding imagemagick- one more time fixed the problem.

1.) emerge =imagemagick-

2.) perl -MImage::Magick -e'print "OK\n";'
Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/' for module Image::Magick: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.7/i686-linux/ line 230.
 at -e line 0
Compilation failed in require.
BEGIN failed--compilation aborted.

3.) objdump -p /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/
Dynamic Section:

4) emerge imagemagick

5) perl -MImage::Magick -e'print "OK\n";'

6.) objdump -p /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/
Dynamic Section:
Comment 1 Mark Clegg 2006-02-02 12:34:23 UTC
I've noticed the same. For info, running revdep-rebuild catches it, forcing a re-build of ImageMagick-
Comment 2 Decibels 2006-02-02 18:46:12 UTC
Required a rebuild here also on two different computers. Was running revdep-rebuild after updating system.
Revdep was longer than ever seen it, with mostly libMagick errors.

Rebuilding imagemagick worked.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-02-03 07:10:46 UTC
*** Bug 121434 has been marked as a duplicate of this bug. ***
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-02-04 00:49:01 UTC
*** Bug 121509 has been marked as a duplicate of this bug. ***
Comment 5 Stefaan De Roeck (RETIRED) gentoo-dev 2006-02-05 13:09:59 UTC
This is not just a problem with the perl library.  I needed, looking further into the problem, I get these similar results (on my amd64-stable):

given a system with imagemagick-
# emerge imagemagick (currently
# ldd /usr/lib64/
--- => not found

and the other way around:
# emerge =media-gfx/imagemagick-
# ldd /usr/lib64/
--- => not found

emerging the same version twice solves the problem
Comment 6 Nathan Adams 2006-02-05 13:37:21 UTC
This seems to work for me:

# cd /usr/lib
# ln -s
Comment 7 Stefaan De Roeck (RETIRED) gentoo-dev 2006-02-05 13:56:45 UTC
> This seems to work for me:
> # cd /usr/lib
> # ln -s

I wouldn't do that. It's dirty, it's a hack, ...
Just re-emerging imagemagick would give you a clean and working system.
Comment 8 Nathan Adams 2006-02-05 14:15:18 UTC
Re-emerging imagemagick- (twice) did not create on my system. dvd::rip is still looking for; so the 'dirty hack' will have to do until the ebuild is fixed.

dvd::rip Message:

Job 'Determine number of titles' failed.

Executed command: dr_exec tcprobe -H 10 -i /home/nate/jk04 && echo DVDRIP_SUCCESS

Last output was:

tcprobe: error while loading shared libraries: cannot open shared object file: No such file or directory
Comment 9 Stefaan De Roeck (RETIRED) gentoo-dev 2006-02-05 14:28:44 UTC
The solution is not to create, but to make other packages build against the new  You can do that using revdep-rebuild if the problem is in a gentoo-supplied binary.  

That, or ImageMagick would need to be slotted, so so.6 and so.9 can live together.
Comment 10 Nathan Adams 2006-02-05 19:39:52 UTC
revdep-rebuild found transcode. Re-emerging transcode did the trick. Thanks!
Comment 11 Sven 2006-02-08 08:38:42 UTC
Same here: the perl-library was linked against the old system-wide version instead the newly compiled one.

This is either a problem with the ebuild not taking proper care of compiling the perl-library, or the build-system of imagemagick.
Comment 12 Thomas Petersen 2006-02-13 01:59:29 UTC
Same problem here.
In my case however even all modules in /usr/lib/ImageMagick-6.2.5/modules-Q16/coders is linking against making ImageMagick completely useless as it can't read or write any image formats.
Reemerging fixes it.
It seems like during the build process it links against the libMagick that is already installed instead of the newly compiled version.
Comment 13 Karol Wojtaszek (RETIRED) gentoo-dev 2006-02-14 23:15:08 UTC
Yes i know that imagemagick links against libMagick installed in the system instead of just compiled in package. But i can't find why makefiles are doing so.
Comment 14 Martin von Gagern 2006-04-23 15:15:04 UTC
This problem reminds me of bug #119776 comment #20. There as well a new build seems to be linked against an already installed old library instead of the newly built one. Maybe a generic solution to all issues of this kind can be found.
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2006-06-24 01:07:28 UTC
*** Bug 137798 has been marked as a duplicate of this bug. ***
Comment 16 Alex Efros 2006-07-11 05:13:57 UTC
This bug is still exists in ~86 imagemagick- :(
And it's really annoying. ImageMagick on my Barton 3000 compile about
11 minutes... add revdep-rebuild, then again ImageMagick = 30 minutes.

> But i can't find why makefiles are doing so.
I think this is because problem isn't in makefiles. :-)
Looks like you should give additional params to `perl Makefile.PL`,
so it will use .so files from work/ dir instead of system-wide.
+myconf="LIBS=-L/path/to/current/so/" perl-app_src_prep
I'm not sure which params and in which format should be given,
but I think it may looks this way.
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2006-07-14 09:37:05 UTC
*** Bug 140374 has been marked as a duplicate of this bug. ***
Comment 18 Rudo Thomas 2006-07-16 02:39:57 UTC
The problem is still there, even after imagemagick- has been marked stable. Sigh.
Comment 19 Sven 2006-07-18 00:55:26 UTC
Hmm, are we making any progress here?

@Karol: have you asked the imagemagick-developers how to fix the problem? this is becoming a really annoying :-(
Comment 20 Erik Wasser 2006-07-18 03:06:07 UTC
I can confirm the annoying level of this bug! B-(
Comment 21 Sven 2006-07-18 04:24:29 UTC
Sorry, but i just have to copy&paste some information from the file called PerlMagick/README.TXT


    Get the PerlMagick distribution and type the following:

        gunzip ImageMagick-6.0.2-2.tar.gz
        tar xvf ImageMagick-6.0.2

    Follow the ImageMagick installation instructions in INSTALL-unix.txt
                then type

      cd PerlMagick

    Next, edit Makefile.PL and change LIBS and INC to include the appropriate
    path information to the required libMagick library. You will also need
    library search paths (-L) to JPEG, PNG, TIFF, etc. libraries if they were
    included with your installed version of ImageMagick. If an extension
    library is built as a shared library but not installed in the system's
    default library search path, you may need to add run-path information
    (often -R or -rpath) corresponding to the equivalent library search
    path option so that the library can be located at run-time.

Or in other words: is editing Makefile.PL the proper sollution for out problem?

Well, i took a look into Makefile.PL, and guess what i've found:

'INC'        => '-I../ -I.. -I/usr/include/freetype2 -I/usr/include/libxml2',
'LIBS'       => ['-L/usr/lib -L../magick/.libs -lMagick -lfreetype -lz -L/usr/lib -llcms -ltiff -lfreetype -ljpeg -lfreetype -lz -lfontconfig -lexpat -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lpthread -lm -lpthread'],

So INC looks proper ...
But LIBS does not! /usr/lib is first, and that's why PerlMagick gets linked against the library already installed in /usr/lib/ instead of the newly compiled one.

So a simple patch could be:
replace "-L/usr/lib -L../magick/.libs" by "-L../magick/.libs -L/usr/lib".

So this should be reported to the ImageMagick developers. I would say, it's a bug.

Perhaps, it can can be fixed simply by using "sed" in the ebuild to change the "-L"-ordner as suggested above.

Thanks for reading :-)
Comment 22 Sven 2006-07-18 04:34:58 UTC

LDFLAGS and LDDFLAGS are also polluted with a "-L/usr/bin" which can be dropped, IMHO.

The call to the link now finally looks like this:

i686-pc-linux-gnu-gcc  -shared -L/usr/local/lib Magick.o  -o blib/arch/auto/Image/Magick/ -L/var/tmp/portage/imagemagick- -L/usr/bin -lMagick -lfreetype -lz -L/usr/lib -llcms -ltiff -lfreetype -ljpeg -lfreetype -lz -lfontconfig -lexpat -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lpthread -lm -lpthread

As you can see, /usr/bin is now in the second place, and not in the first place.
Comment 23 Sven 2006-07-18 05:20:27 UTC
I wrote /usr/bin instead of /usr/lib in my last comments. That happens, when you don't copy&paste and did not have your coffee yet. Sorry!
Comment 24 Sven 2006-07-19 08:29:07 UTC
Created attachment 92213 [details, diff]
the patch for the current ebuild
Comment 25 Sven 2006-07-19 08:29:34 UTC
Created attachment 92214 [details, diff]
the patch for PerlMagick/
Comment 26 Sven 2006-07-19 08:33:47 UTC
Is somebody willing to test this?

well, so here's what i've done:
- replaced --without-perl by $(use_with perl) so that configure uses to recreate Makefile.PL
- moved the "-L" options from LIBS to LD(D)FLAGS where they IMHO belong, and did also put them in proper order

Now, the linker-call looks like this:
i686-pc-linux-gnu-gcc  -L../magick/.libs -L/usr/lib -shared -L/usr/local/lib Magick.o  -o blib/arch/auto/Image/Magick/ -lMagick -llcms -ltiff -lfreetype -ljpeg -lfreetype -lz -lfontconfig -lexpat -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lpthread -lm -lpthread

Looks right, doesn't it?
Comment 27 Sven 2006-07-19 09:37:31 UTC

The patches don't work (yet). The problem is the following:

after a "configure --with-perl", the command "make all" behaves as we need it: it builds ImageMagick, but not the perl-library. But then, for a sick reason, "make install" seems to build the perl-library again.

So i guess, that's the reason why the maintainer did always use "--without-perl" - but, well - but int that case, we have the drawback, that Makefile.PL is not created property - but Makefile.PL _MUST_ be created by configure, because the default Makefile.PL contains lots of libraries not needed depending on the use-flags.

BTW: do you see the sick reason, why "make install" compiles and installs the perl-module? The sick reason is, that the ImageMagick developers seem to know, that they _first_ have to install the new ImageMagick to /usr/lib before using it by compiling PerlMagick.

Well, so here's the question for which we need an answer:
How to patch/convince ImageMagick's configure/Makefile to recreate Makefile.PL (like with "--with-perl"), but not to compile or install the perl-module?

Any help would be appreciated.
Comment 28 Sven 2006-07-19 10:55:26 UTC
Created attachment 92225 [details, diff]
patch for the ebuild
Comment 29 Sven 2006-07-19 10:55:52 UTC
Created attachment 92226 [details, diff]
patch for PerlMagick/ and PerlMagick/
Comment 30 Sven 2006-07-19 10:58:30 UTC
New patches! Would be nice, if you test them

The problem has now been solved by:
- Patching LD(D)FLAGS and LIBS in PerlMagick/
- Patching PerlMagick/, so that the perl-module won't be compiled/installed along with ImageMagick itself
- some minor patches in the ebuild

For me, this works! I did the test: i downgraded ImageMagick, reinstalled the new one. The perl-library worked!
Comment 31 Jakub Moc (RETIRED) gentoo-dev 2006-07-25 00:36:52 UTC
*** Bug 141658 has been marked as a duplicate of this bug. ***
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-08-08 00:19:23 UTC
*** Bug 143157 has been marked as a duplicate of this bug. ***
Comment 33 Walter Dnes 2006-08-08 22:50:22 UTC
(In reply to comment #30)
> New patches! Would be nice, if you test them

  I'd love to, but I'm not a programmer.  Can you give me step-by-step instructions how to do it?  Thanks.
Comment 34 Sven 2006-08-09 12:25:30 UTC

Download "patch for PerlMagick/ ..." from the Attachement-List above, and copy it to /usr/portage/media-gfx/imagemagick/files/imagemagick-perl.patch.

Then download "patch for the ebuild" to another file, and do the following:

cd /usr/portage/media-gfx/imagemagick/
cat /path/to/the/second/file | patch --dry-run

If that works correctly, then run the last command again without the "--dry-run".

Then, to test it, downgrade to some old imagemagick-version, and then update to again. Note, that the patched ebuild will be gone after your next "emerge --sync".
Comment 35 Sven 2006-08-09 12:51:59 UTC

i forgot something. After applying the patch to the ebuild, you have to run:
  ebuild imagemagick- digest

Then it will not complain about wrong checksums/filesizes ;-)
Comment 36 Sven 2006-08-09 13:51:56 UTC

i think, that my patches are quite mature - and they fix also the issue, that Makefile.PL doesn't get recreated by configure (which is important IMHO, if many --without-XYZ options were used).

I would appreciate a comment.
(Mainly, because i want to see this bug fixed)
Comment 37 Walter Dnes 2006-08-09 20:24:54 UTC
(In reply to comments #34 and #35)

Doesn't work for me.  I can only go back to, which may not be "early" enough.  Earlier ebuilds blow up on me with the png_atr bug during the compile.

In the past, my "solution" would be to stay 2 or 3 ebuilds behind the current version.  That doesn't work today, thanks to the png_atr bug.  If you run

FEATURES="keepwork" emerge =imagemagick.a.b.c.d

for various ebuilds "a.b.c.d", you'll find that they generate diffent versions of, with the older versions generating versions from 6 to 9.  What settings are in those ebuilds that cause diffent versions of to be generated?

I'll see if I can download the tarball and do my "pseudo-rpm" install...
./configure --with-various-options && make && make install
Comment 38 Walter Dnes 2006-08-09 21:55:14 UTC
(In reply to comment #37)

Actually it *DOES* work.  I didn't follow the instructions exactly the first time.  Thank you for your help.  I took some pictures on the weekend that I want to upload to a website, and this issue was blocking me.  I can now proceed.  Thanks again.
Comment 39 Walter Dnes 2006-08-10 14:27:07 UTC
(In reply to comment #30)
> New patches! Would be nice, if you test them

  On my second attempt, I did get it to compile, and it mostly works.  Can you backport your patches to the ebuild?  In my bug # 122511 submission, I noted that the current version of "convert" always seems to have problems with certain ugly, but legal, expressions.  Same thing is happening now.

  "convert" from older versions of imagemagick always seemed to work OK with that stuff.  That's another reason I stay behind by a couple of ebuild versions.  The ebuild is the oldest ebuild that doesn't blow up with the png_attr bug.  I also find that "display" exhibits the opposite behaviour, i.e. the newer builds of imagemagick "display" work OK, older versions don't.  However, there are are hundreds of image viewers out there, but only 1 "convert" program, so I'm mostly worried about "convert". for more details.
Comment 40 Walter Dnes 2006-08-11 23:28:11 UTC
Never mind the backport.  I've finally got everything working.  I'll be adding a note closing out bug # 122511.  The work-around is to run a dummy "convert" pass to convert a "tif" to a tif.  "convert" can then do all sorts of fancy stuff on the converted version.  My guess is that my Panasonic FZ5 camera creates non-standard tiff files that can't be easily manipulated, but can be converted to a standard tiff file.  Now that I know the root cause of the problem, I can take it to the imagemagick mailing list, and throw in a sample file.
Comment 41 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-09-05 07:58:19 UTC
(In reply to comment #36)
> @Maintainer:
> i think, that my patches are quite mature - and they fix also the issue, that

You could try send the patches upstream, maybe they would include them for next release :)

Comment 42 Sven 2006-09-05 08:24:15 UTC
(In reply to comment #41)
> (In reply to comment #36)
> > @Maintainer:
> > 
> > i think, that my patches are quite mature - and they fix also the issue, that
> You could try send the patches upstream, maybe they would include them for next
> release :)

Yes. It's a good idea for PerlMagick/ - but the rest is ebuild-specific.
Normally, the steps "./configure --with-perl; make all" will also build the perl-module. But for the ebuild, the building of the perl-module was seperated from the main building process. But the ebuilds still needs to run "configure --with-perl" so that Makefile.PL gets recreated and contains the right list of libraries. So the patch for will remain. (Hmm, or maybe i can override it within the call to make? never tried yet)
Comment 43 Sven 2006-09-05 09:23:42 UTC
Created attachment 96080 [details, diff]
new patch for current imagemagick-

This patch for the ebuild doesn't need patching of PerlMagick/ anymore! This is a great advantage, because we also don't need to run eautoreconf anymore.

The make-variables in PerlMagick/ that needed patching, are now overridden by passing them to make directly. Is has the same effect as the patch.

There is also a negative side: the patch of PerlMagick/ will fail, if something gets changed. This method will silently go wrong.
Comment 44 Sven 2006-09-05 09:24:48 UTC
Created attachment 96081 [details, diff]
new patch for PerlMagick/

new patch for the recent patch of the ebuild
Comment 45 Michael Cummings (RETIRED) gentoo-dev 2006-09-15 16:35:07 UTC
fwiw, the $(use_with perl) really doesn't achieve anything. Here's the result as reported by ImageMagick:

PERL              --with-perl=no                no

Anyway, here's the result of your patch. Sorry,

4:21 )-( imagemagick )-(  538 )
$ perl
use Image::Magick;
perl: symbol lookup error: /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Image/Magick/ undefined symbol: InitializeMagick
Comment 46 Sven 2006-09-15 17:15:49 UTC
Please! I don't know what commands you ran, but i checked it:

I applied the patch (attachement 96080) to the ebuild of imagemagick
The other patch isn't need anymore, as it seems, because it went upstream, it seems.

Then i ran:
USE="perl" ebuild imagemagick- digest clean compile

The result of configure was:
config.status: creating PerlMagick/Makefile.PL
PERL              --with-perl=yes               /usr/bin/perl

I could even see, that configure get's invoked with "--with-perl" as it should be.

The i ran
USE="perl" ebuild imagemagick- digest clean compile

The output of configure:
PERL              --with-perl=no                no

Exactly as it should be.

So now i'm trying to reproduce the error with PerlMagick's - any hints on how to reproduce?
Comment 47 Sven 2006-09-15 17:21:18 UTC
I just noticed one small thing:

configure also re-creates Makefile.PL is "--without-perl" is used. Can you confirm?

Then, as it seems, you don't need any of my patches anymore. If the patch for is now upstream (and if i'm not blind, then it is), then problems are all fixed with the release of
Comment 48 Sven 2006-09-16 17:51:48 UTC
Comment on attachment 96081 [details, diff]
new patch for PerlMagick/

The patch for is not needed anymore. The ImageMagick developers accepted it. It's included since version
Comment 49 Sven 2006-09-16 17:53:04 UTC
Comment on attachment 96080 [details, diff]
new patch for current imagemagick-

The patch for the ebuild is also not needed anymore. The problems i tried to patch never existed. Running configure with "--without-perl" is pretty fine.
Comment 50 Sven 2006-09-16 18:45:16 UTC
I tested the current ebuilds that are in portage right now.
Here are the results:

# downgrade to version,
emerge -1 =media-gfx/imagemagick-
perl -e "use Image::Magick;"
# => module raises error, as expected
# module searches for previously installed

# rebuild version again:
emerge -1 =media-gfx/imagemagick-
perl -e "use Image::Magick;"
# => now module works

# now upgrade to version,
emerge -1 =media-gfx/imagemagick-
perl -e "use Image::Magick;"
# => works

So i don't see any need for further patching. The problem is solved now.
Comment 51 Michael Cummings (RETIRED) gentoo-dev 2006-09-18 07:59:12 UTC
Your testing is flawed. You have to completely unmerge imagemagick first, not downgrade it. Here is the result of installing after a complete unmerge of imagemagick:

$ perl -e "use Image::Magick;"
perl: symbol lookup error: /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Image/Magick/ undefined symbol: InitializeMagick
Comment 52 Sven 2006-09-18 09:15:10 UTC
what did you do? a or b?

emerge -C media-gfx/imagemagick
emerge -1 =media-gfx/imagemagick-
emerge -C media-gfx/imagemagick
emerge -1 =media-gfx/imagemagick-
emerge -1 =media-gfx/imagemagick-
Comment 53 Michael Cummings (RETIRED) gentoo-dev 2006-09-18 09:39:41 UTC
emerge --unmerge imagemagick

emerge imagemagick 
(which on my box is because I allow ~arch).

Comment 54 Sven 2006-09-18 09:45:11 UTC
So i testes this:

emerge -C media-gfx/imagemagick
emerge -1 =media-gfx/imagemagick-

And yes, i can reproduce the "undefined symbol: InitializeMagick" on both x86 and amd64.

I don't understand it yet, but i will investigate. 
Comment 55 Sven 2006-09-18 13:14:38 UTC
Problem found:

when you run "perl Makefile.PL" there is warning:
Note (probably harmless): No library found for -lMagick

And this is not harmless, because the "-lMagick" is removed from the parameters that the linker is called with.

That warning is generated by ExtUtils::MakeMaker. From my point of view, it's a bug, because MakeMaker should include all those paths that are specified within the LDFLAGS and LDDLFLAGS variables during his search.

I have to invetigate further. If anybody knows a sollution, let me know.
Comment 56 Sven 2006-09-18 16:22:34 UTC
Created attachment 97370 [details, diff]
Fix for the case, that imagemagick is not installed already

I didn't manage to tell MakeMaker to include -L option from LDFLAGS or LDDLFLAGS. Actually i moved the "-lMagick" to those two variables. It will definitely not be removed anymore.

I will send the patch to the imagemagick-devel mailinglist in a few moments. It will be discussed there.
Comment 57 Sven 2006-09-18 16:27:43 UTC
Oh sorry: only the part of the patch concerning is needed. The part about doesn't matter for us.
Comment 58 Michael Cummings (RETIRED) gentoo-dev 2006-09-19 07:21:58 UTC
latest patch works. For a quick diff on the ebuilds (I removed all of the perl cruft to see if it was still needed - doesn't appear so):

--- /usr/portage/media-gfx/imagemagick/imagemagick-       2006-09- 16 17:06:02.000000000 -0400
+++ imagemagick-  2006-09-19 06:57:26.000000000 -0400
@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/media-gfx/imagemagick/imagemagick- uild,v 1.8 2006/09/16 21:06:01 vapier Exp $

-inherit eutils perl-app multilib
+inherit eutils multilib

@@ -54,13 +54,14 @@ src_unpack() {
        cd "${S}"
        chmod +x config.sub
        epatch "${FILESDIR}"/${PN}-
+       epatch "${FILESDIR}"/imagemagick-perl.patch

 src_compile() {
        econf \
                --with-threads \
                --with-modules \
-               --without-perl \
+               $(use_with perl) \
                --with-gs-font-dir=/usr/share/fonts/default/ghostscript \
                --with-windows-font-dir=/usr/share/fonts/corefonts \
                $(use_with !nocxx magick-plus-plus) \
@@ -83,11 +84,6 @@ src_compile() {
                || die "econf failed"
        emake || die "compile problem"

-       if use perl ; then
-               cd PerlMagick
-               perl-app_src_prep
-               perl-app_src_compile
-       fi

 src_install() {
@@ -100,8 +96,4 @@ src_install() {
        ! use doc && rm -r "${D}"/usr/share/doc/${PF}/html
        dodoc NEWS ChangeLog AUTHORS README.txt QuickStart.txt Install-unix.txt

-       if use perl ; then
-               cd PerlMagick
-               perl-module_src_install
-       fi
Comment 59 Sven 2006-09-19 08:06:06 UTC
Patch has been applied upstream. Next ImageMagick-version should include the modifications.
Comment 60 Michael Cummings (RETIRED) gentoo-dev 2006-09-20 19:22:25 UTC
patch applied in tree to imagemagic-6..2.9.5-r1. Thanks Sven!