# emerge =dev-php5/magickwand-1.0.6 ... checking whether to enable the magickwand extension... yes, shared checking Wand-config in default path... found in /usr/bin checking for magick-wand.h header file... configure: error: Cannot locate header file magick-wand.h ... # qlist imagemagick | grep /magick-wand.h\$ /usr/include/ImageMagick/wand/magick-wand.h # Wand-config --cflags -I/usr/include/ImageMagick # Wand-config --prefix /usr Looking at the configure script or its input, config.m4, I notice that it looks for $(Wand-config --prefix)/include/wand/magick-wand.h and calls PHP_ADD_INCLUDE with that prefix. Looking at aclocal.m4, there is a function PHP_EVAL_INCLINE for just this situation, i.e. to handle the output of Wand-config --cflags instead. I'll try turn this into a patch to attach here.
Created attachment 147952 [details, diff] First attempt at patch, won't work OK, I've investigated the matter some more. The first part of the attached patch changes from "Wand-config --prefix" and PHP_ADD_INCLUDE to "Wand-config --cppflags" and PHP_EVAL_INCLINE. I've thrown in an AC_CHECK_HEADER for good measure, though I'm not sure if there is any portability gain to be expected from this. That's the theory. In practice, however, the include flag path won't be added to the compiler arguments. Adding a -x to configure, it looks like this unique calculation in PHP_RUN_ONCE doesn't do what you would expect. The brackets in this regular expression are missing, as are some other brackets in some other regular expressions as well. I don't know why that's so, I'm not really an autotools wizard. The most robust solution seems to use quadrigraphs instead of changequote. The second part of the patch tried to do this, but it turned out that aclocal.m4 wasn't even present at the time src_unpack has its chance to patch things. It seems the broken regular expression orginates from dev-lang/php-5.2.6_rc3-r1, from /usr/lib/php5/lib/php/build/acinclude.m4 to be more precise. Relevant part of emerge --info: Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.2.3, glibc-2.7-r2, 2.6.24-gentoo-r3 i686) ================================================================= System uname: 2.6.24-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Timestamp of tree: Tue, 01 Apr 2008 08:48:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.3.6-r2, 2.4.4-r4, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 dev-lang/php: 5.2.6_rc3-r1 (apache2 bcmath berkdb bzip2 cgi cli crypt ctype curl doc exif flatfile force-cgi-redirect ftp gd gdbm iconv imap ipv6 kerberos ldap mhash mysql ncurses nls oci8-instant-client odbc pcntl pcre pic posix postgres readline reflection session snmp soap sockets spell spl sqlite ssl tokenizer truetype unicode xml xmlreader xmlwriter xsl zlib -adabas -birdstep -calendar -cdb -cjk -concurrentmodphp -curlwrappers -db2 -dbase -dbmaker -debug -discard-path -empress -empress-bcs -esoob -fastbuild -fdftk -filter -firebird -frontbase -gd-external -gmp -hash -inifile -interbase -iodbc -java-external -json -ldap-sasl -libedit -mcve -msql -mssql -mysqli -oci8 -pdo -qdbm -recode -sapdb -sharedext -sharedmem -simplexml -solid -suhosin -sybase -sybase-ct -sysvipc -threads -tidy -wddx -xmlrpc -xpm -yaz -zip -zip-external)
Created attachment 149560 [details, diff] Make better use of Wand-config OK, here is a second attempt, which works for me at least. The problems with the SED command described in comment #1 were due to lack of quotations in my m4 code. Can't say I really like that language. So there is no problem with the acinclude.m4 from php itself. Although I got the header check to work with proper quotations, I decided to drop fail-fast configure checks in favor of simplicity. The compiler will complain soon enough when the required header isn't there, so there is no urgent need for configure to check that. The patch simply passes output from Wand-config to the proper PHP_EVAL_* functions. I'll try push this upstream as well. But I'd hope for Gentoo to include this patch shoon, without waiting for upstream.
Lacking better means of contact, I reported this in an upstream forum: http://www.imagemagick.org/discourse-server/viewtopic.php?f=10&t=11023
Created attachment 149581 [details, diff] Patch for 1.0.7 There were some modifications to config.m4 in 1.0.7, which cause that version to build out of the box on my system with media-gfx/imagemagick-6.3.9.7, making the patches submitted here not strictly necessary. However, I'd assume that an unpatched 1.0.7 would faild for older versions of imagemagick which are still allowed as deoendencies by both ebuild and configure script. E.g. media-gfx/imagemagick-6.3.5.10 does not have the newer directory layout with an ImageMagick directory, as it is assumed by dev-php5/magickwand-1.0.7. This patch here is the one from comment #2, ported to 1.0.7, and augmented by the correction of an obvious typo. As there seem to be only compile time changes between 1.0.6 and 1.0.7, and no improvements to runtime behaviour, there is no urgent need to bump to 1.0.7 as long as 1.0.6 does compile. On the other hand, there are no strong reasons against a bump either. If you do bump, including this patch should ensure compatibility with the whole range of imagemagick versions allowed by the dependency settings of the ebuild.
ping!
*** Bug 224813 has been marked as a duplicate of this bug. ***
Your patch doesnt apply against 1.0.7 here: /tmp/MagickWandForPHP-1.0.7 $ patch -p1 -i /home/christian/Gentoo/gentoo-x86/dev-php5/magickwand/files/imagemagick-pre-6.3.9-compat.patch patching file config.m4 Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 3 out of 3 hunks ignored -- saving rejects to file config.m4.rej I simply bumped the imagemagick dependency to 6.3.9.7, as I'm neither able to install any previous imagemagick version nor does the patch work. magickwand does not have a stable version anyway, so it's not a high priority to get it working with stable imagemagick.
Created attachment 156089 [details, diff] Patch for 1.0.7-1 (In reply to comment #7) > Your patch doesnt apply against 1.0.7 here: They changed the upstream tarball. My patch was against a tarball with md5 sum c3c0aa0135e91dab7828075eb05c9cc2 instead of dc816e74ccf0bafa4249fdce7fb19ce5 as it is now. The new tarball contains portions of my patch, and the ChangeLog even references the forum thread I opened. It seems to be derived from the repository trunk, as the 1.0.7 branch contains no such modification. In the ChangeLog it is called 1.0.7-1. According to the configure script this version depends on imagemagick 6.3.8, but as the script uses MagickWand-config and the Gentoo version of e.g. imagemagick-6.3.8.3-r1 still only provides Wand-config, the unpatched 1.0.7-1 release will still require newer imagemagick, like stated in your fix. Alternatively you can use attached patch to use Wand-config instead of MagickWand-config in order to lower the dependency.
Reopen
Thanks -- the more supported versions we have, the better, so I applied your patch (again, without a revbump as it is a buildtime-only problem). Thanks for the patch and it would be nice if you could actually try building against an older version of imagemagick (stable should be fine). Latest ~amd64 still works fine with this patch, so it should not introduce any regression. ;)
Created attachment 156211 [details, diff] Patch for 1.0.7-1 (In reply to comment #10) > Thanks for > the patch and it would be nice if you could actually try building against an > older version of imagemagick (stable should be fine) Seems I have overlooked quite a few occurrences of MagickWand-config in the original configure script. Sorry, should have tested this more thoroughly here myself. With this corrected patch here, I get magickwand compiled against media-gfx/imagemagick-6.3.5.10.
I am running imagemagick-6.3.8.3-r1 on amd64 and I can confirm that the latest patch posted here allows magickwand-1.0.7 to build. Please update portage with the latest patch.
Thanks again, updated patch committed to the tree. Leaving at TEST-REQUEST until someone confirms that the in-tree version indeed works (I only tested building against latest ~arch imagemagick).
