-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There seems to be a lot of issues in the build process on Mac OS X,
not to mention once you get them squared away the build still doesn't
work without editing the makefile and adding '-framework
ApplicationServices'
Trying to build on Mac OS X, configuring fails if you build ICU in
the manner they instruct for building ICU for Mac OS X.
It always fails at the libxml test (I know why).
config.nice:
#! /bin/sh
Created by configure
CFLAGS=''
LDFLAGS=''
'./configure'
'--prefix=/usr/local/php'
'--with-icu-dir=/usr/local/icu'
'--with-libxml-dir=/usr'
'--with-apxs' \
gets to:
Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... /usr
checking for xml2-config path... /usr/bin/xml2-config
checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for
details.
From the config.log it appears to have a problem linking the ICU
library and I believe this is related to not saving the runtime
paths, a note for Mac OSX should be included explaining this issue to
prevent unwanted back-chatter, for the faint at heart, the easiest
solution is to build ICU with '--disable-shared --enable-static'.
configure:27665: checking for location of ICU headers and libraries
configure:27704: result: found in /usr/local/icu
configure:27707: checking for ICU 3.4 or greater
configure:27715: result: found 3.6
configure:27847: result:
configure:27849: result: Configuring extensions
configure:27866: checking whether to enable LIBXML support
configure:27904: result: yes
configure:27913: checking libxml2 install dir
configure:27931: result: /usr
configure:27943: checking for xml2-config path
configure:27957: result: /usr/bin/xml2-config
configure:28100: checking whether libxml build works
configure:28132: gcc -o conftest -O0 -no-cpp-precomp -framework
CoreServices -framework ApplicationServices -L/usr/local/icu/lib -L/
usr/local/icu/lib conftest.c
-lm -lm -licui18n -licuuc -licudata -lm -licuio -lxml2 -lz
- -liconv -lm >&5
configure:28135: $? = 0
configure:28137: ./conftest
dyld: Library not loaded: libicui18n.dylib
Referenced from: /SourceCache/BuildSmart/PHP504/srcroot/
php6.0-200701121130/./conftest
Reason: image not found
../configure: line 1: 3796 Trace/BPT trap ./conftest$ac_exeext
configure:28140: $? = 133
At this time I've reworked the ICU binaries to be Mac OS X
environment complaint and the configure now progresses as expected.
+++++++
The included imap extension fails to build as well as the pdo_dblib
extension.
For the imap extension I had to add:
#ifdef HAVE_NEW_MIME2TEXT
#undef HAVE_NEW_MIME2TEXT
#endif
to get it to build as it complained with:
/SourceCache/php6/ext/imap/php_imap.c:84: error: conflicting types
for 'utf8_mime2text'
/usr/local/imap/include/utf8.h:466: error: previous declaration of
'utf8_mime2text' was here
and I figured this out to be related to the 2006c1 and newer API and
I'm using the 2004g source so a different check is required to
determine which library API is really valid.
+++++++
After examining the pdo_dblib code, I found the code supplied with
php-5.2.0 to be newer and seems to build and work without any issues
(some modification required).
GD doesn't appear to work properly, I have a small script that
populates text on a generated png image and serves it but it doesn't
seem to output anything and I'm not seeing any error messages.
Thinking that this might be a GD code related issue I swapped out the
gd from 5.2.0 (with some modification) but it exhibits the exact same
issue where it never outputs the image (my script can be supplied if
someone needs it) but works as intended under 5.x.x.
+++++++
I tried enabling display_errors and when I do, I see messages about
'utf8 is not support, assuming iso-8859-1' throughout the phpinfo()
page so I added the following to ext/standard/html.c:
{ "utf8", cs_utf_8 },
which seems to have resolved this.
+++++++
Now that I have PHP-6 built, installed and configured I'm seeing a
lot of errors related to 'Strict Standards' (I thought his could be
turned off but it doesn't) and even worse, pear doesn't appear to
work citing too many issues.
SEE: (example)
http://www.daleenterprise.com:8081/maia/admin/configtest.php
+++++++
The following php script code exhausts memory.
// PHP Modules
`ob_start()`;
phpinfo(INFO_MODULES);
$php_info = `ob_get_contents()`;
`ob_end_clean()`;
I've set up a real-time site for development testing so that I can
test in real-time cause what may work in a dev environment doesn't
always work in real-life.
http://www.daleenterprise.com:8081/
http://www.daleenterprise.com:8081/maia/admin/configtest.php
Examine:
http://www.daleenterprise.com:8081/info.php
Look at 'Registered PHP Streams', 'Registered Stream Socket
Transports' and 'Registered Stream Filters'
Everything you see at port 8081 you can access at port 80.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFFq0YC0hzWbkf0eKgRAneEAKC89hbRwdI6Zk6YCbC4kT5p0qnYHgCfdStT
s88MIQJPlgOJuImjDvgJsZM=
=+Sz3
-----END PGP SIGNATURE
<skip> > From the config.log it appears to have a problem linking the ICU > library and I believe this is related to not saving the runtime > paths, a note for Mac OSX should be included explaining this issue to > prevent unwanted back-chatter, for the faint at heart, the easiest > solution is to build ICU with '--disable-shared --enable-static'. <skip> > > At this time I've reworked the ICU binaries to be Mac OS X > environment complaint and the configure now progresses as expected.-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1There seems to be a lot of issues in the build process on Mac OS X,
not to mention once you get them squared away the build still doesn't
work without editing the makefile and adding '-framework
ApplicationServices'Trying to build on Mac OS X, configuring fails if you build ICU in
the manner they instruct for building ICU for Mac OS X.
Do you think this is PHP problem?
It looks like ICU issue to me.
+++++++
The included imap extension fails to build as well as the pdo_dblib
extension.For the imap extension I had to add:
#ifdef HAVE_NEW_MIME2TEXT
#undef HAVE_NEW_MIME2TEXT
#endifto get it to build as it complained with:
/SourceCache/php6/ext/imap/php_imap.c:84: error: conflicting types
for 'utf8_mime2text'
/usr/local/imap/include/utf8.h:466: error: previous declaration of
'utf8_mime2text' was hereand I figured this out to be related to the 2006c1 and newer API and
I'm using the 2004g source so a different check is required to
determine which library API is really valid.
PHP looks for "mail_append_set" im mail.h (which is present only in new versions of c-client)
and uses new utf8_mime2text() semantics if it's present.
If you have BOTH "mail_append_set" and old "utf_mime2text()", then it's likely you have some problems with the headers.
After examining the pdo_dblib code, I found the code supplied with
php-5.2.0 to be newer and seems to build and work without any issues
(some modification required).GD doesn't appear to work properly, I have a small script that
populates text on a generated png image and serves it but it doesn't
seem to output anything and I'm not seeing any error messages.
Could you please elaborate?
A short but complete reproduce script would be most welcome.
I tried enabling display_errors and when I do, I see messages about
'utf8 is not support, assuming iso-8859-1' throughout thephpinfo()
page so I added the following to ext/standard/html.c:
{ "utf8", cs_utf_8 },
which seems to have resolved this.
Probably, because it's "utf-8", not "utf8".
Though, I don't really understand what you're talking about here..
Now that I have PHP-6 built, installed and configured I'm seeing a
lot of errors related to 'Strict Standards' (I thought his could be
turned off but it doesn't) and even worse, pear doesn't appear to
work citing too many issues.
SEE: (example)
http://www.daleenterprise.com:8081/maia/admin/configtest.php
So... ?
E_STRICT
is definitely not PHP problem. but a problem of your code.
The following php script code exhausts memory.
// PHP Modules `ob_start()`; phpinfo(INFO_MODULES); $php_info = `ob_get_contents()`; `ob_end_clean()`;
Could you please explain what do you mean by "exhausts memory" ?
--
Wbr,
Antony Dovgal
Examine:
http://www.daleenterprise.com:8081/info.phpLook at 'Registered PHP Streams', 'Registered Stream Socket
Transports' and 'Registered Stream Filters'
This should be fixed in CVS.
--
Wbr,
Antony Dovgal