PHP issues.

php.internals

Dale Walsj

19 years ago
-----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-----

Antony Dovgal

19 years ago
On 01/15/2007 12:14 PM, BuildSmart wrote:
> -----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.
<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.
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 > #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.
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 the phpinfo() > 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

Antony Dovgal

19 years ago
On 01/15/2007 12:14 PM, BuildSmart wrote:
> Examine: > http://www.daleenterprise.com:8081/info.php > > Look at 'Registered PHP Streams', 'Registered Stream Socket > Transports' and 'Registered Stream Filters'
This should be fixed in CVS.
-- Wbr, Antony Dovgal