/imagick ... need to get a copy to work with
Imagick is now working on 7; you will need to use the PHP 7 branch
from https://github.com/mkoppanen/imagick/tree/phpseven
Opening any issues you might find on Github would probably get them
resolved more quickly than bugs.php.net due to the more direct
notifications.
I'm going to take this opportunity to suggest everyone who saves
images to PNG format should upgrade to at least ImageMagick 6.8.9-7.
There was a pretty nasty image corruption issue on previous versions
which showed up occasionally.
cheers
Dan
Opening any issues you might find on Github would probably get them
resolved more quickly than bugs.php.net due to the more direct
notifications.
I'm getting a
unknown type name ‘smart_str’ after failing to find php_smart_str.h
because my php7 build has php_smart_string.h. Along with a lot of
deprecated warnings. I'll post more to github when I get a chance to
compare with previous builds.
I've got similar problems with magickwand as well but it's been 4 years
since I last built the libraries for that. I presume I need to change a
lot of type entries on that?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I'm getting a
unknown type name ‘smart_str’ after failing to find php_smart_str.h
because my php7 build has php_smart_string.h.
Apologies - this was caused by the filename being changed in the PHP
src, and me compiling against the version left in the
/usr/local/include/php directory. It is fixed now.
btw, apparently 'make distclean' doesn't seem to clean up the header
files in '/usr/local/include/php/ext/' for me at least on Centos.
cheers
Dan
I'm getting a
unknown type name ‘smart_str’ after failing to find php_smart_str.h
because my php7 build has php_smart_string.h.
Apologies - this was caused by the filename being changed in the PHP
src, and me compiling against the version left in the
/usr/local/include/php directory. It is fixed now.btw, apparently 'make distclean' doesn't seem to clean up the header
files in '/usr/local/include/php/ext/' for me at least on Centos.
That has fixed imagick, but I can't get phpinfo to run on the rebuilt
php-fpm after syncing with the pdo changes. Not sure where I went wrong,
but pdo_sqlite is complaining about the API change yet has the new
source ...
Just running from a clean build to see what happens ...
OK - nginx is now starting clean, but when I enable imagick extension
then running phpinfo fails. The extension seems to be working OK otherwise.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Dan Ackroyd in php.internals (Mon, 26 Jan 2015 17:58:40 +0000):
/imagick ... need to get a copy to work with
Imagick is now working on 7; you will need to use the PHP 7 branch
from https://github.com/mkoppanen/imagick/tree/phpseven
Did you compile that with the git head of php-src? I did and stumbled
into some problems.
ext/standard/php_smart_string_public.h is now almost empty. You should
include ext/standard/php_smart_string.h and change some functions:
https://github.com/Jan-E/imagick/commit/243c206cf5528255b406a76e1807dd64af209ced
Z_BVAL_P does not exist anymore. Possible fix:
-
convert_to_boolean(multiline); -
query_multiline = Z_BVAL_P(multiline);
-
convert_to_double(multiline); -
query_multiline = Z_DVAL_P(multiline);
See
https://github.com/Jan-E/imagick/commit/c0711521a926ba8fed7b61ae106c6d9039fc71f4
And besides that there were the usual fixes for VC11 and a few
deprecated functions. See all my commits at:
https://github.com/Jan-E/imagick/commits/phpseven
After these commits php_imagick.dll compiled with VC11 and (for Lester)
showed itself in phpinfo:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm
Complete build:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip
Jan
After these commits php_imagick.dll compiled with VC11 and (for Lester)
showed itself in phpinfo:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm
Progress ...
But mine is not listing the supported formats :(
http://php7.lsces.org.uk/phpinfo.php
http://hg.lsces.org.uk/hg/imagick/rev/7aec3f35fc99 is the patch I
applied Dan
Now need to check when imagemagick update will appear in SUSE ;)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine in php.internals (Wed, 28 Jan 2015 09:03:14 +0000):
After these commits php_imagick.dll compiled with VC11 and (for Lester)
showed itself in phpinfo:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htmProgress ...
But mine is not listing the supported formats :(
http://php7.lsces.org.uk/phpinfo.php
This happens when the extension cannot find the installed IM-filters,
AFAIK. Strangely enough I saw the same happen with the x64 VC11 build
for PHP7 (phpseven branch). But the x64 VC11 builds do show the
supported formats (master branch).
http://hg.lsces.org.uk/hg/imagick/rev/7aec3f35fc99 is the patch I
applied Dan
Hmm, your patch reminds me of
https://github.com/Jan-E/imagick/commits/phpseven ;-)
The patches for the deprecated functions are already present in the
imagick-master, but not in the phpseven branch. Maybe there are more
differences between master and phpseven that explain the difference in
supported formats between PHP 5.6 and PHP7.
Jan
Lester Caine in php.internals (Wed, 28 Jan 2015 09:03:14 +0000):
After these commits php_imagick.dll compiled with VC11 and (for Lester)
showed itself in phpinfo:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htmProgress ...
But mine is not listing the supported formats :(
http://php7.lsces.org.uk/phpinfo.php
This happens when the extension cannot find the installed IM-filters,
AFAIK. Strangely enough I saw the same happen with the x64 VC11 build
for PHP7 (phpseven branch). But the x64 VC11 builds do show the
supported formats (master branch).http://hg.lsces.org.uk/hg/imagick/rev/7aec3f35fc99 is the patch I
applied Dan
Hmm, your patch reminds me of
https://github.com/Jan-E/imagick/commits/phpseven ;-)The patches for the deprecated functions are already present in the
imagick-master, but not in the phpseven branch. Maybe there are more
differences between master and phpseven that explain the difference in
supported formats between PHP 5.6 and PHP7.
This is perhaps an example of where the basic structure of PHP code is a
problem. I have the code used for the current production extension which
is I think from a period when it was still part of php-src. Trying to
compare that with the current builds across multiple forks is just
messy. Just which fork should I use ...
I've got the same problem with interbase/firebird for a slightly
different reason ... it's development history is buried in php-src.
In the good old days of CVS one simply created a 'view' of a modular
repository selecting the modules you wanted ... freezing or forking a
module for a new composite build. This is something neither git or hg
considered had any place in DVCS when they were first developed, and
while 'sub-repo' is begrudgingly supported in both these days it is not
considered 'the proper way to work'. For projects like PHP I consider it
essential in order to avoid the sort of hacking such as
https://github.com/m6w6/php-src/tree/merge-http
PEAR also fits into a proper model where all of the elements we can use
for a distributed build ARE available as elements, and a distribution
either creates a series of shared packages or a single static build bu
from the whole code base rather than some cherry picked subset + the
elements that are no longer considered by some developers ...
Just where do I go for an 'unloved' extension or add-on ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk