Yesterday I built imagemagick-6.2.5.5 and the Magick.so file from the perl extension was linked against libMagick.so.6 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-6.2.5.5 one more time fixed the problem. Steps: 1.) emerge =imagemagick-6.2.5.5 2.) perl -MImage::Magick -e'print "OK\n";' Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/Magick.so' for module Image::Magick: libMagick.so.6: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm 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/Magick.so .... Dynamic Section: NEEDED libMagick.so.6 .... 4) emerge imagemagick 5) perl -MImage::Magick -e'print "OK\n";' OK 6.) objdump -p /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/auto/Image/Magick/Magick.so .... Dynamic Section: NEEDED libMagick.so.9 ....
I've noticed the same. For info, running revdep-rebuild catches it, forcing a re-build of ImageMagick-6.2.5.5.
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.
*** Bug 121434 has been marked as a duplicate of this bug. ***
*** Bug 121509 has been marked as a duplicate of this bug. ***
This is not just a problem with the perl library. I needed libWand.so, looking further into the problem, I get these similar results (on my amd64-stable): given a system with imagemagick-6.2.4.2-r1 # emerge imagemagick (currently 6.2.5.5) # ldd /usr/lib64/libWand.so --- libMagick.so.6 => not found --- and the other way around: # emerge =media-gfx/imagemagick-6.2.4.2-r1 # ldd /usr/lib64/libWand.so --- libMagick.so.9 => not found --- emerging the same version twice solves the problem
This seems to work for me: # cd /usr/lib # ln -s libMagick.so.9.0.5 libMagick.so.6
> This seems to work for me: > > # cd /usr/lib > # ln -s libMagick.so.9.0.5 libMagick.so.6 I wouldn't do that. It's dirty, it's a hack, ... Just re-emerging imagemagick would give you a clean and working system.
Re-emerging imagemagick-6.2.5.5 (twice) did not create libMagick.so.6 on my system. dvd::rip is still looking for libMagick.so.6; 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: libMagick.so.6: cannot open shared object file: No such file or directory
The solution is not to create libMagick.so.6, but to make other packages build against the new libMagick.so.9. 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.
revdep-rebuild found transcode. Re-emerging transcode did the trick. Thanks!
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.
Same problem here. In my case however even all modules in /usr/lib/ImageMagick-6.2.5/modules-Q16/coders is linking against libMagick.so.6 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.
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.
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.
*** Bug 137798 has been marked as a duplicate of this bug. ***
This bug is still exists in ~86 imagemagick-6.2.8.0. :( 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. -perl-app_src_prep +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.
*** Bug 140374 has been marked as a duplicate of this bug. ***
The problem is still there, even after imagemagick-6.2.8.0 has been marked stable. Sigh.
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 :-(
I can confirm the annoying level of this bug! B-(
Sorry, but i just have to copy&paste some information from the file called PerlMagick/README.TXT Installation 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 :-)
Note: 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/Magick.so -L/var/tmp/portage/imagemagick-6.2.8.0/work/ImageMagick-6.2.8/PerlMagick/../magick/.libs -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.
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!
Created attachment 92213 [details, diff] the patch for the current ebuild
Created attachment 92214 [details, diff] the patch for PerlMagick/Makefile.PL.in
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 Makefile.PL.in 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/Magick.so -lMagick -llcms -ltiff -lfreetype -ljpeg -lfreetype -lz -lfontconfig -lexpat -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lpthread -lm -lpthread Looks right, doesn't it?
Damn! 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.
Created attachment 92225 [details, diff] patch for the ebuild
Created attachment 92226 [details, diff] patch for PerlMagick/Makefile.am and PerlMagick/Makefile.PL.in
New patches! Would be nice, if you test them The problem has now been solved by: - Patching LD(D)FLAGS and LIBS in PerlMagick/Makefile.PL.in - Patching PerlMagick/Makefile.am, 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!
*** Bug 141658 has been marked as a duplicate of this bug. ***
*** Bug 143157 has been marked as a duplicate of this bug. ***
(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.
@Walter: Download "patch for PerlMagick/Makefile.am ..." 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 6.2.8.0 again. Note, that the patched ebuild will be gone after your next "emerge --sync".
@Walter: i forgot something. After applying the patch to the ebuild, you have to run: ebuild imagemagick-6.2.8.0.ebuild digest Then it will not complain about wrong checksums/filesizes ;-)
@Maintainer: 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)
(In reply to comments #34 and #35) Doesn't work for me. I can only go back to 6.2.6.0, 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 libMagick.so, with the older versions generating versions from 6 to 9. What settings are in those ebuilds that cause diffent versions of libMagick.so 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
(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.
(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 6.2.6.0 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 6.2.6.0 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". http://bugs.gentoo.org/show_bug.cgi?id=122511 for more details.
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.
(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 :)
(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/Makefile.PL.in - 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 Makefile.am will remain. (Hmm, or maybe i can override it within the call to make? never tried yet)
Created attachment 96080 [details, diff] new patch for current imagemagick-6.2.8.0.ebuild This patch for the ebuild doesn't need patching of PerlMagick/Makefile.am anymore! This is a great advantage, because we also don't need to run eautoreconf anymore. The make-variables in PerlMagick/Makefile.am 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/Makefile.am will fail, if something gets changed. This method will silently go wrong.
Created attachment 96081 [details, diff] new patch for PerlMagick/Makefile.PL.in new patch for the recent patch of the ebuild
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/Magick.so: undefined symbol: InitializeMagick
Please! I don't know what commands you ran, but i checked it: I applied the patch (attachement 96080) to the ebuild of imagemagick 6.2.9.5. The other patch isn't need anymore, as it seems, because it went upstream, it seems. Then i ran: USE="perl" ebuild imagemagick-6.2.9.5.ebuild 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-6.2.9.5.ebuild 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 Magick.so - any hints on how to reproduce?
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 Makefile.PL.in is now upstream (and if i'm not blind, then it is), then problems are all fixed with the release of 6.2.9.5
Comment on attachment 96081 [details, diff] new patch for PerlMagick/Makefile.PL.in The patch for Makefile.PL.in is not needed anymore. The ImageMagick developers accepted it. It's included since version 6.2.9.5.
Comment on attachment 96080 [details, diff] new patch for current imagemagick-6.2.8.0.ebuild 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.
I tested the current ebuilds that are in portage right now. Here are the results: # downgrade to version 6.2.5.5, libMagick++.so.9: emerge -1 =media-gfx/imagemagick-6.2.5.5 perl -e "use Image::Magick;" # => module raises error, as expected # module searches for previously installed libMagick++.so.10 # rebuild version 6.2.5.5 again: emerge -1 =media-gfx/imagemagick-6.2.5.5 perl -e "use Image::Magick;" # => now module works # now upgrade to version 6.2.9.5, libMagick++.so.10: emerge -1 =media-gfx/imagemagick-6.2.9.5 perl -e "use Image::Magick;" # => works So i don't see any need for further patching. The problem is solved now.
Your testing is flawed. You have to completely unmerge imagemagick first, not downgrade it. Here is the result of installing 6.2.9.5 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/Magick.so: undefined symbol: InitializeMagick
what did you do? a or b? a) emerge -C media-gfx/imagemagick emerge -1 =media-gfx/imagemagick-6.2.9.5 b) emerge -C media-gfx/imagemagick emerge -1 =media-gfx/imagemagick-6.2.5.5 emerge -1 =media-gfx/imagemagick-6.2.9.5
emerge --unmerge imagemagick emerge imagemagick (which on my box is 6.2.9.5 because I allow ~arch).
So i testes this: emerge -C media-gfx/imagemagick emerge -1 =media-gfx/imagemagick-6.2.9.5 And yes, i can reproduce the "undefined symbol: InitializeMagick" on both x86 and amd64. I don't understand it yet, but i will investigate.
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.
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.
Oh sorry: only the part of the patch concerning Makefile.PL.in is needed. The part about Makefile.am doesn't matter for us.
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-6.2.9.5.ebuild 2006-09- 16 17:06:02.000000000 -0400 +++ imagemagick-6.2.9.5.ebuild 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-6.2.9.5.eb uild,v 1.8 2006/09/16 21:06:01 vapier Exp $ -inherit eutils perl-app multilib +inherit eutils multilib MY_PN=ImageMagick MY_P=${MY_PN}-${PV%.*} @@ -54,13 +54,14 @@ src_unpack() { cd "${S}" chmod +x config.sub epatch "${FILESDIR}"/${PN}-6.2.5.4-docs.patch + 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 }
Patch has been applied upstream. Next ImageMagick-version should include the modifications.
patch applied in tree to imagemagic-6..2.9.5-r1. Thanks Sven!
