[PHP-DEV] Bug #14965 Updated: Sablotron XLST encoding error
ID: 14965
Comment by: [EMAIL PROTECTED]
Old Reported By: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
Unless the below is a typo, it's quite logical:
while (!feof ($xmlfile)) {
$xml_file_contents = fgets($xmlfile, 4096);
//echo $xml_file_contents;
}
should read:
while (!feof ($xmlfile)) {
/notice the dot
$xml_file_contents .= fgets($xmlfile, 4096);
//echo $xml_file_contents;
}
Unless you have an xmlfile, consisting of 1 line, smaller that 4096
bytes, $xml_file_contents, will consist of the last line only.
Previous Comments:
[2002-01-14 08:21:44] [EMAIL PROTECTED]
Hi,
I can confrim Feddy's code works fine on Windows 2000 (thanks Freddy
:), however the code I submitted earlier still produces the error so
using either file or HTTP with fopen and using the array arguments of
xslt_process function still produces the error.
Andrew
[2002-01-14 07:32:41] [EMAIL PROTECTED]
On Windows 98, Apache 1.3.22, PHP 4.1.1, Sablotron 0.71, I experienced
the same problem with 'xslt_process()', which I was able to solve using
the 'file://' specifier:
$result = xslt_process($xh,
'file://E:/Web/test.xml',
'file://E:/Web/test.xsl');
Strange enough, since the command:
$result = xslt_process($xh, 'test.xml', 'test.xsl');
runs just fine on FreeBSD 4.4, Apache 1.3.22, PHP 4.1.1, Sablotron
0.71. On Windows however, the above command gives me error code 4:
cannot open file 'd:/programs/apache/test.xsl'
because Sablotron is looking for the xsl file in the Apache program
directory. After specifying the full file name for the xsl file:
$result = xslt_process($xh, 'test.xml',
'E:/Web/test.xsl');
I receive error code 63:
unknown encoding ''
After using the 'file://' prefix for the xsl file and a full file name
for the xml file, I receive error code 2:
XML parser error 9: junk after document element
Only when using the 'file://' prefix for both the xsml and xsl file,
xslt_process() seems to work fine for Windows:
$result = xslt_process($xh,
'file://E:/Web/test.xml',
'file://E:/Web/test.xsl');
See also:
http://archive.gingerall.cz/archives/sablot/msg01858.html
HTH, Freddy Vulto
[2002-01-10 14:40:03] [EMAIL PROTECTED]
slight correction to my last message it should read
$file_path = C:\\test\\;
:)
Andrew
[2002-01-10 14:35:45] [EMAIL PROTECTED]
Hi,
$DOCUMENT_ROOT is a blank variable
also trying the file path rather than HTTP e.g.
$file_path = C://test//;
Produces the same error.
All paths are correct
Andrew
[2002-01-10 14:21:41] [EMAIL PROTECTED]
moved to Documentation problem
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14965
Edit this bug report at http://bugs.php.net/?id=14965edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11612 Updated: php_include completely non-functional
ID: 11612 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PHP options/info functions Operating System: Win2k Server PHP Version: 4.0.5 New Comment: Should be reclassified as documentation problem. Use: 1) a full reference including the disk, i.e.: .;c:\include\path 2) For virtual hosts, the document root in Apache httpd.conf should follow the same principles, i.e.: DocumentRoot c:\www\demoxpress.com\html Previous Comments: [2002-01-13 13:09:55] [EMAIL PROTECTED] Still have the same problem: Some configuartion: Win2000 pro, apache 1.3.14 and PHP4.1.1 if the include_path is empty.. no problem if I put anything in eg 'include_path = .;\apache\htdocs\ error message is like this: 'Warning: Failed opening '/apache/htdocs/phpinfo.php' for inclusion (include_path='.') in Unknown on line 0' Everything works fine, if there´s nothing in the include_path. Do you have a solution in the meantime? [2001-12-18 16:21:08] [EMAIL PROTECTED] Did more testing, always works for me. [2001-12-18 15:56:18] [EMAIL PROTECTED] On my Win2k box it works just fine, include_path has always been '.' only. It worked with PHP 4.0.6 and still works with 4.1.0. Your problem must be caused by something else. [2001-06-24 02:28:42] [EMAIL PROTECTED] nope, exactly the same. :( [2001-06-23 06:30:59] [EMAIL PROTECTED] Does it work with PHP 4.0.6? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11612 Edit this bug report at http://bugs.php.net/?id=11612edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11612 Updated: php_include completely non-functional
ID: 11612 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: Win2k Server PHP Version: 4.0.5 New Comment: The warning should probably go into: http://www.php.net/manual/en/install.windows.php The root of this problem, is not the include_path, but the DocumentRoot Apache directive - or any document root setting on a windows webserver. While any path syntax works for Apache, only windows native works for php. This goes for ISAPI as well, under other webservers, like Sambar. Don't have IIS, so I haven't tested it there. Further more \ is not always the root of the current disk. I suppose it is, but current probably is current for c:\winnt\system32\php4_ts.dll instead of the webserver executable. Haven't fully debugged that. In any case, specifying document roots in the windows native path syntax, prefixed with the drive letter, fixes all of the above. Previous Comments: [2002-01-13 15:02:35] [EMAIL PROTECTED] Make this to doc problem. Current http://www.php.net/manual/en/configuration.php uses full path. What should be fixed? [2002-01-13 13:34:44] [EMAIL PROTECTED] Should be reclassified as documentation problem. Use: 1) a full reference including the disk, i.e.: .;c:\include\path 2) For virtual hosts, the document root in Apache httpd.conf should follow the same principles, i.e.: DocumentRoot c:\www\demoxpress.com\html [2002-01-13 13:09:55] [EMAIL PROTECTED] Still have the same problem: Some configuartion: Win2000 pro, apache 1.3.14 and PHP4.1.1 if the include_path is empty.. no problem if I put anything in eg 'include_path = .;\apache\htdocs\ error message is like this: 'Warning: Failed opening '/apache/htdocs/phpinfo.php' for inclusion (include_path='.') in Unknown on line 0' Everything works fine, if there´s nothing in the include_path. Do you have a solution in the meantime? [2001-12-18 16:21:08] [EMAIL PROTECTED] Did more testing, always works for me. [2001-12-18 15:56:18] [EMAIL PROTECTED] On my Win2k box it works just fine, include_path has always been '.' only. It worked with PHP 4.0.6 and still works with 4.1.0. Your problem must be caused by something else. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11612 Edit this bug report at http://bugs.php.net/?id=11612edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11612 Updated: php_include completely non-functional
ID: 11612 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: Win2k Server PHP Version: 4.0.5 New Comment: Please read: The document root in -- Apache's httpd.conf --. Look at your warning: 'Warning: Failed opening '/apache/htdocs/index.php' Why doesn't that read: 'Warning: Failed opening 'c:\apache\htdocs\index.php' ? Previous Comments: [2002-01-13 15:49:48] [EMAIL PROTECTED] Sorry, problem is still alive: Now I use the following: ; Windows: \path1;\path2 include_path = .;c:\apache\htdocs\eucarkunden ; The root of the PHP pages, used only if nonempty. doc_root = c:\apache\htdocs Problem is the same 'Warning: Failed opening '/apache/htdocs/index.php' for inclusion (include_path='.;c:\apache\htdocs\eucarkunden') in Unknown on line 0' [2002-01-13 15:23:02] [EMAIL PROTECTED] The warning should probably go into: http://www.php.net/manual/en/install.windows.php The root of this problem, is not the include_path, but the DocumentRoot Apache directive - or any document root setting on a windows webserver. While any path syntax works for Apache, only windows native works for php. This goes for ISAPI as well, under other webservers, like Sambar. Don't have IIS, so I haven't tested it there. Further more \ is not always the root of the current disk. I suppose it is, but current probably is current for c:\winnt\system32\php4_ts.dll instead of the webserver executable. Haven't fully debugged that. In any case, specifying document roots in the windows native path syntax, prefixed with the drive letter, fixes all of the above. [2002-01-13 15:02:35] [EMAIL PROTECTED] Make this to doc problem. Current http://www.php.net/manual/en/configuration.php uses full path. What should be fixed? [2002-01-13 13:34:44] [EMAIL PROTECTED] Should be reclassified as documentation problem. Use: 1) a full reference including the disk, i.e.: .;c:\include\path 2) For virtual hosts, the document root in Apache httpd.conf should follow the same principles, i.e.: DocumentRoot c:\www\demoxpress.com\html [2002-01-13 13:09:55] [EMAIL PROTECTED] Still have the same problem: Some configuartion: Win2000 pro, apache 1.3.14 and PHP4.1.1 if the include_path is empty.. no problem if I put anything in eg 'include_path = .;\apache\htdocs\ error message is like this: 'Warning: Failed opening '/apache/htdocs/phpinfo.php' for inclusion (include_path='.') in Unknown on line 0' Everything works fine, if there´s nothing in the include_path. Do you have a solution in the meantime? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11612 Edit this bug report at http://bugs.php.net/?id=11612edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14965 Updated: Sablotron XLST encoding error
ID: 14965 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Sablotron XSL Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: You set the path as an http:// url. By default, Sablotron doesn't provide an http handler, nor does the current xslt extension. This also applies to external entities and dtd's. Use the arg:/_xml syntax and fetch the url's first (fopen or even better with the curl extension) = Should be documentation problem as the file open method is not specified and could be interpreted as the php fopen. Previous Comments: [2002-01-10 11:21:43] [EMAIL PROTECTED] are you sure the filenames you passed are correct? i got the same message yesterday and the reason was an empty stylesheet due to a missing global declaration (i was using variables instead of files but it looks like the same problem - nonexistant xslt input) [2002-01-10 08:35:57] [EMAIL PROTECTED] Dear Sirs, I have come across an issue with the Sablotron XSLT extension. The issue is similar to the issue reported to http://bugs.php.net/bug.php?id=14499 however my encoding has been set. Using Windows 2000 Server SP 2, PHP 4.1.1 and IIS 5.0 I tested the following code. XML ?xml version=1.0 encoding=UTF-8? PEOPLE PERSON NAMEAndrew/NAME /PERSON /PEOPLE XSL ?xml version=1.0 encoding=UTF-8? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ html head/ body xsl:apply-templates/ /body /html /xsl:template xsl:template match=NAME span style=display:list-item; font-family:Arial span style=display:list-item; font-family:Arial xsl:apply-templates/ /span /span /xsl:template /xsl:stylesheet PHP ? //path $file_path = http://localhost/;; //xml file $xml_file = $file_path . people.xml; //xsl file $xsl_file = $file_path . people.xslt; // Allocate a new XSLT processor $xh = xslt_create(); // Process the document $result = xslt_process($xh, $xml_file, $xsl_file); xslt_free($xh); ? From this script the following error is returned: Warning: Sablotron error on line 1: unknown encoding '' in c:\stuff\xlst_transform.php on line 18 line 18 is the following $result = xslt_process($xh, $xml_file, $xsl_file); The following adapation of the XSL file also gives the same result. ?xml version=1.0? xsl:output method=xml encoding=UTF-8/ xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=NAME span style=display:list-item; font-family:Arial xsl:apply-templates/ /span /xsl:template /xsl:stylesheet I also tested the code using Apache 1.3.22 under Windows 2000 server with the same result. Andrew Stopford Edit this bug report at http://bugs.php.net/?id=14965edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14870: GD breaks SIGUSR1 and SIGHUP
From: [EMAIL PROTECTED] Operating system: BSDi 4.x PHP version: 4.0CVS-2002-01-05 PHP Bug Type: GD related Bug description: GD breaks SIGUSR1 and SIGHUP First some details: gd version: 2.0.1, using custom Makefile (will send it seperately to the php-dev list). Tested OS: BSDi 4.2, but bug exists in elder versions of all components (OS/PHP/GD) When apache receives a SIGUSR1, the childs start cycling, eating CPU power and causing a load of appr. 3 per apache child. A SIGHUP doesn't work correctly: [Sat Jan 5 13:52:57 2002] [notice] caught SIGTERM, shutting down [Sat Jan 5 13:55:56 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations [Sat Jan 5 13:55:56 2002] [notice] Accept mutex: flock (Default: flock) [Sat Jan 5 13:56:00 2002] [warn] child process 18897 did not exit, sending another SIGHUP [Sat Jan 5 13:56:00 2002] [warn] child process 18898 did not exit, sending another SIGHUP [Sat Jan 5 13:56:00 2002] [warn] child process 18899 did not exit, sending another SIGHUP [Sat Jan 5 13:56:00 2002] [warn] child process 18900 did not exit, sending another SIGHUP [Sat Jan 5 13:56:00 2002] [warn] child process 18901 did not exit, sending another SIGHUP [Sat Jan 5 13:56:02 2002] [warn] child process 18897 still did not exit, sending a SIGTERM [Sat Jan 5 13:56:02 2002] [warn] child process 18898 still did not exit, sending a SIGTERM [Sat Jan 5 13:56:02 2002] [warn] child process 18899 still did not exit, sending a SIGTERM [Sat Jan 5 13:56:02 2002] [warn] child process 18900 still did not exit, sending a SIGTERM [Sat Jan 5 13:56:02 2002] [warn] child process 18901 still did not exit, sending a SIGTERM [Sat Jan 5 13:56:06 2002] [error] child process 18897 still did not exit, sending a SIGKILL [Sat Jan 5 13:56:06 2002] [error] child process 18898 still did not exit, sending a SIGKILL [Sat Jan 5 13:56:06 2002] [error] child process 18899 still did not exit, sending a SIGKILL [Sat Jan 5 13:56:06 2002] [error] child process 18900 still did not exit, sending a SIGKILL [Sat Jan 5 13:56:06 2002] [error] child process 18901 still did not exit, sending a SIGKILL [Sat Jan 5 13:56:06 2002] [notice] SIGHUP received. Attempting to restart [Sat Jan 5 13:56:06 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations [Sat Jan 5 13:56:06 2002] [notice] Accept mutex: flock (Default: flock) All this disappears, when eliminating gd from the equasion. I think the cause lies in the linking of the library. Even though I have configured php to use the shared version: --with-gd=shared,/weblib/local \ --with-freetype-dir=/weblib/local gd is linked into libphp4.so: $ ldd libphp4.so ./libphp4.so = ./libphp4.so (0x4805b000) libdl.so = /shlib/libdl.so (0x481f9000) libm.so = /shlib/libm.so.0.0 (0x481fd000) libsablot.so.0 = /weblib/local/lib/libsablot.so.0 (0x4820e000) libexpat.so.0 = /weblib/local/lib/libexpat.so.0 (0x482b6000) libmysqlclient.so.10 = /weblib/local/lib/mysql/libmysqlclient.so.10 (0x482d7000) libiconv.so.2 = /weblib/local/lib/libiconv.so.2 (0x482f4000) libgd.so.2 = /weblib/local/lib/libgd.so.2 (0x483c9000) libfreetype.so.6 = /weblib/local/lib/libfreetype.so.6 (0x483fc000) libssl.so.0.9.6 = /weblib/local/lib/libssl.so.0.9.6 (0x4843) libcrypto.so.0.9.6 = /weblib/local/lib/libcrypto.so.0.9.6 (0x484e6000) libc.so.2 = /shlib/libc.so.2 (0x485a8000) libgcc.so.1 = /shlib/libgcc.so.1 (0x48674000) libz.so = /usr/lib/libz.so (0x48681000) libpng.so.2 = /weblib/local/lib/libpng.so.2 (0x4869) The shared lib in lib/php/20010901-debug only links itself and the standard c libs: $ ldd libgd.so ./libgd.so = ./libgd.so (0x4805b000) libc.so.2 = /shlib/libc.so.2 (0x4807) libgcc.so.1 = /shlib/libgcc.so.1 (0x4813c000) If I compare this to pg for instance, it is not in the php4 lib and it shows proper linking with the pg native libs: $ ldd libpgsql.so ./libpgsql.so = ./libpgsql.so (0x4805b000) libpq.so.2 = /pgsql/lib/libpq.so.2 (0x48069000) libc.so.2 = /shlib/libc.so.2 (0x48079000) libgcc.so.1 = /shlib/libgcc.so.1 (0x48145000) libssl.so.0.9.6 = /weblib/local/lib/libssl.so.0.9.6 (0x48152000) libcrypto.so.0.9.6 = /weblib/local/lib/libcrypto.so.0.9.6 (0x48208000) libdl.so = /shlib/libdl.so (0x482ca000) The reason I need a custom Makefile for gd, is because the standard gd library Makefile, creates a libgd.so, which generates a crash on startup of apache, and ldd on this library, doesn't even detect any dependancies, nor does it give 'statically linked' - just a blank line. -- Edit bug report at: http://bugs.php.net/?id=14870edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL
[PHP-DEV] Bug #14804: PHP_AUTH_* - what is it?
From: [EMAIL PROTECTED]
Operating system: Any
PHP version: 4.1.1
PHP Bug Type: Documentation problem
Bug description: PHP_AUTH_* - what is it?
Please see:
http://www.php.net/manual/en/language.variables.predefined.php
as opposed to:
http://www.php.net/manual/en/features.http-auth.php
PHP_AUTH vars, are not listed in the Apache list, while the features page,
qualifies them as such.
Under ISAPI however, these vars are available as:
AUTH_PASSWORD and AUTH_USER, so people looking for a reason why their
script won't work, either bum out, when viewing the second page, or look at
phpinfo and see nothing, because you need to be logged in first, to see
them (yes, there are ways less obvious).
So, either they should be listed as Apache variables in the first page, or
they should not be called Apache variables in the second page.
In any case, I think mentioning, they are called differently in ISAPI on
the second page, is not a luxury.
Also - I think example 17-1 should be changed to:
?php
if (!isset($_SERVER['REMOTE_USER'])) {
header(WWW-Authenticate: Basic realm=\My Realm\);
header(HTTP/1.0 401 Unauthorized);
echo Text to send if user hits Cancel button\n;
exit;
} else {
// The variables below could be called differently.
// If so, change the code below to phpinfo() and look
// them up
echo pHello $PHP_AUTH_USER./p;
echo pYou entered $PHP_AUTH_PW as your password./p;
}
?
which should work on any platform, that supports the feature, independant
of register_globals settings.
--
Edit bug report at: http://bugs.php.net/?id=14804edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14804 Updated: PHP_AUTH_* - what is it?
ID: 14804
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.1.1
New Comment:
Correction:
the $PHP_AUTH_USER and $PHP_AUTH_PW in the bottom half of the example script, should
be changed to their $_SERVER equivalent also.
Previous Comments:
[2002-01-02 12:44:04] [EMAIL PROTECTED]
Please see:
http://www.php.net/manual/en/language.variables.predefined.php
as opposed to:
http://www.php.net/manual/en/features.http-auth.php
PHP_AUTH vars, are not listed in the Apache list, while the features page, qualifies
them as such.
Under ISAPI however, these vars are available as:
AUTH_PASSWORD and AUTH_USER, so people looking for a reason why their script won't
work, either bum out, when viewing the second page, or look at phpinfo and see
nothing, because you need to be logged in first, to see them (yes, there are ways less
obvious).
So, either they should be listed as Apache variables in the first page, or they should
not be called Apache variables in the second page.
In any case, I think mentioning, they are called differently in ISAPI on the second
page, is not a luxury.
Also - I think example 17-1 should be changed to:
?php
if (!isset($_SERVER['REMOTE_USER'])) {
header(WWW-Authenticate: Basic realm=\My Realm\);
header(HTTP/1.0 401 Unauthorized);
echo Text to send if user hits Cancel button\n;
exit;
} else {
// The variables below could be called differently.
// If so, change the code below to phpinfo() and look
// them up
echo pHello $PHP_AUTH_USER./p;
echo pYou entered $PHP_AUTH_PW as your password./p;
}
?
which should work on any platform, that supports the feature, independant of
register_globals settings.
Edit this bug report at http://bugs.php.net/?id=14804edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: BSD/OS 4.x PHP Version: 4.1.0 New Comment: Of course it was the last extension - in this case GD. BSDi 4.2 now comes with both a shared zlib as a shared Jpeg. The zlib is ok, but I've made a jpeg 6.2 of my own. There are a number of issues now surfacing, so should I open a new report on GD/BSDi 4.2 for these (HUP signal doesn't work anymore, linking with 2 libraries installed, makes it core dump)? Remaining for this report: 1) incorrect detection of HAVE_RES_SEARCH braking getmxrr and other DNS related functions, work-around: $ diff -c php_config.h.in php_config.h.in.dist *** php_config.h.in Fri Dec 14 21:13:55 2001 --- php_config.h.in.distFri Dec 14 15:06:29 2001 *** *** 1894,1903 #define zend_finite(a) (zend_isnan(a) ? 0 : zend_isinf(a) ? 0 : 1) #endif - #ifdef __bsdi__ - #define HAVE_RES_SEARCH 1 - #endif - /* * Local variables: * tab-width: 4 --- 1894,1899 I have provided an example of how bind-9.x detects this function. 2) Release versions need a fix of the include statements in various files, since the old make syntax is used, for BSDi's system provided make, instead of the make preferred in the PATH and/or specified by $MAKE. This does not apply to snapshots. Previous Comments: [2001-12-15 06:43:11] [EMAIL PROTECTED] Those yacc warnings are harmless. [2001-12-15 05:37:28] [EMAIL PROTECTED] Ok, working on it. 2 notes on this build: I get a lot of yacc warnings like these: /usr/src/web/php/php4/ext/standard/var_unserializer.re:273: warning: label `yy1' defined but not used And the XtOffsetOf is redefined: In file included from /apbeta/include/httpd.h:72, from sapi_apache.c:32: /apbeta/include/ap_config.h:1367: warning: `XtOffsetOf' redefined [2001-12-14 21:23:50] [EMAIL PROTECTED] So with the minimum options everything works just fine? If so, then please try adding some more options and see when it starts to fail. --Jani [2001-12-14 15:40:06] [EMAIL PROTECTED] Ok, you can rule that out. Compiles outof the box. Build php4-200112140600. [2001-12-13 21:41:38] [EMAIL PROTECTED] Please try the latest CVS snapshot with this configure line: --with-apxs=/apache/bin/apxs --without-mysql --disable-pear --disable-xml --disable-session --enable-debug As I first want to rule out any extension being the reason for the segfault. --Jani The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=14048 Edit this bug report at http://bugs.php.net/?id=14048edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: *Configuration Issues Operating System: BSD/OS 4.x PHP Version: 4.1.0 New Comment: Ok, you can rule that out. Compiles outof the box. Build php4-200112140600. Previous Comments: [2001-12-13 21:41:38] [EMAIL PROTECTED] Please try the latest CVS snapshot with this configure line: --with-apxs=/apache/bin/apxs --without-mysql --disable-pear --disable-xml --disable-session --enable-debug As I first want to rule out any extension being the reason for the segfault. --Jani [2001-12-13 00:26:11] [EMAIL PROTECTED] needcoffeeoops - sorry about the double posts - I'm not quite awake yet - can you delete that?/needcoffee Indeed I compiled the snapshot from 11120600 and that compiled outof the box - same problem though - core dumps and httpd won't start up. Independant of that - HAVE_RES_SEARCH is still not recognized correctly in both buildtypes. [2001-12-13 00:20:06] [EMAIL PROTECTED] And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? [2001-12-12 18:23:30] [EMAIL PROTECTED] You said before that snapshots have always worked just fine. Is this still the case? Does the latest CVS snapshot work for you? (there might be some problems in creating the releases..) --Jani [2001-12-12 17:47:54] [EMAIL PROTECTED] And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=14048 Edit this bug report at http://bugs.php.net/?id=14048edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Unknown/Other Function Operating System: BSD/OS 4.x Old PHP Version: 4.0.6 PHP Version: 4.0.6 and 4.1.0 New Comment: And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? Previous Comments: [2001-11-19 17:58:03] [EMAIL PROTECTED] You might be having an issue with old shared extension being loaded. Check it first. ie. try disabling the loading of such extensions in php.ini [2001-11-18 22:28:12] [EMAIL PROTECTED] Ok: BSDi 4.2 i386 with GNUmake 3.79.1, autoconf 2.13, automake 1.5, libtool 1.4, configured as: #!/bin/sh ./configure \ --prefix=/php \ --with-perl=/perl/bin/perl \ --with-apxs=/apache/bin/apxs \ --with-config-file-path=/weblib/local/lib \ --with-openssl=/weblib/local \ --disable-short-tags \ --with-zlib \ --with-zlib-dir=/weblib/local \ --enable-bcmath \ --enable-calendar \ --with-curl=shared,/weblib/local \ --with-dom=shared,/weblib/local \ --enable-ftp \ --with-gd=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-freetype-dir=/weblib/local \ --with-iconv=shared,/weblib/local \ --enable-mailparse \ --enable-mbstring \ --with-mcal=shared,/weblib/local \ --with-mcrypt=shared,/weblib/local \ --with-mhash=shared,/weblib/local \ --with-mysql=/weblib/local \ --with-pdflib=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-tiff-dir=/weblib/local \ --with-pgsql=shared,/pgsql \ --enable-sockets \ --with-expat-dir=/weblib/local \ --enable-xslt \ --with-xslt-sablot=shared,/weblib/local \ --with-expat-dir=/weblib/local \ --with-iconv-dir=/weblib/local checking for res_search... no checking for res_search in -lsocket... no checking for res_search in -lresolv... no $ grep -i 'res_search' ./main/php_config.h /* Define if you have the `res_search' function. */ /* #undef HAVE_RES_SEARCH */ This means, that getmxrr() isn't available. checking whether to enable xslt support... yes checking whether to enable the XSLT Sablotron backend... yes, shared checking libexpat dir for Sablotron XSL support... yes checking for iconv_open in -lc... no checking for SablotSetEncoding in -lsablot... yes So - that works now. make now works (always does in snapshots - not in releases). But then, apache won't start: $ gdb -core ./httpd.core -exec apache/bin/httpd GNU gdb Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-bsdi4.2. Core was generated by `httpd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /shlib/libdl.so...done. Reading symbols from /shlib/libgcc.so.1...done. Reading symbols from /shlib/libc.so.2...done. Reading symbols from /shlib/ld-bsdi.so...done. Reading symbols from /apache/libexec/libphp4.so...done. Reading symbols from /weblib/local/lib/libz.so...done. Reading symbols from /weblib/local/lib/libsablot.so.0...done. Reading symbols from /weblib/local/lib/libiconv.so.2...done. Reading symbols from /weblib/local/lib/libexpat.so.0...done. Reading symbols from /weblib/local/lib/libpdf.so.1...done. Reading symbols from /weblib/local/lib/mysql/libmysqlclient.so.10...done. Reading symbols from /weblib/local/lib/libgd.so...done. Reading symbols from /weblib/local/lib/libfreetype.so.6...done. Reading symbols from /weblib/local/lib/libpng.so.2...done. Reading symbols from /weblib/local/lib/libjpeg.so.62...done. Reading symbols from /weblib/local/lib/libssl.so.0.9.6...done. Reading symbols from /weblib/local/lib/libcrypto.so.0.9.6...done. Reading symbols from /shlib/libm.so.0.0...done. Reading symbols
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Old Bug Type: *Configuration Issues Bug Type: Unknown/Other Function Operating System: BSD/OS 4.x PHP Version: 4.0.6 and 4.1.0 New Comment: And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? Previous Comments: [2001-12-12 18:23:30] [EMAIL PROTECTED] You said before that snapshots have always worked just fine. Is this still the case? Does the latest CVS snapshot work for you? (there might be some problems in creating the releases..) --Jani [2001-12-12 17:47:54] [EMAIL PROTECTED] And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? [2001-11-19 17:58:03] [EMAIL PROTECTED] You might be having an issue with old shared extension being loaded. Check it first. ie. try disabling the loading of such extensions in php.ini [2001-11-18 22:28:12] [EMAIL PROTECTED] Ok: BSDi 4.2 i386 with GNUmake 3.79.1, autoconf 2.13, automake 1.5, libtool 1.4, configured as: #!/bin/sh ./configure \ --prefix=/php \ --with-perl=/perl/bin/perl \ --with-apxs=/apache/bin/apxs \ --with-config-file-path=/weblib/local/lib \ --with-openssl=/weblib/local \ --disable-short-tags \ --with-zlib \ --with-zlib-dir=/weblib/local \ --enable-bcmath \ --enable-calendar \ --with-curl=shared,/weblib/local \ --with-dom=shared,/weblib/local \ --enable-ftp \ --with-gd=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-freetype-dir=/weblib/local \ --with-iconv=shared,/weblib/local \ --enable-mailparse \ --enable-mbstring \ --with-mcal=shared,/weblib/local \ --with-mcrypt=shared,/weblib/local \ --with-mhash=shared,/weblib/local \ --with-mysql=/weblib/local \ --with-pdflib=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-tiff-dir=/weblib/local \ --with-pgsql=shared,/pgsql \ --enable-sockets \ --with-expat-dir=/weblib/local \ --enable-xslt \ --with-xslt-sablot=shared,/weblib/local \ --with-expat-dir=/weblib/local \ --with-iconv-dir=/weblib/local checking for res_search... no checking for res_search in -lsocket... no checking for res_search in -lresolv... no $ grep -i 'res_search' ./main/php_config.h /* Define if you have the `res_search' function. */ /* #undef HAVE_RES_SEARCH */ This means, that getmxrr() isn't available. checking whether to enable xslt support... yes checking whether to enable the XSLT Sablotron backend... yes, shared checking libexpat dir for Sablotron XSL support... yes checking for iconv_open in -lc... no checking for SablotSetEncoding in -lsablot... yes So - that works now. make now works (always does in snapshots - not in releases). But then, apache won't start: $ gdb -core ./httpd.core -exec apache/bin/httpd GNU gdb Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-bsdi4.2. Core was generated by `httpd'. Program terminated with signal 11,
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: BSD/OS 4.x PHP Version: 4.0.6 and 4.1.0 New Comment: needcoffeeoops - sorry about the double posts - I'm not quite awake yet - can you delete that?/needcoffee Indeed I compiled the snapshot from 11120600 and that compiled outof the box - same problem though - core dumps and httpd won't start up. Independant of that - HAVE_RES_SEARCH is still not recognized correctly in both buildtypes. Previous Comments: [2001-12-13 00:20:06] [EMAIL PROTECTED] And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? [2001-12-12 18:23:30] [EMAIL PROTECTED] You said before that snapshots have always worked just fine. Is this still the case? Does the latest CVS snapshot work for you? (there might be some problems in creating the releases..) --Jani [2001-12-12 17:47:54] [EMAIL PROTECTED] And it's there again, version 4.1.0: mdev@server6 ~/_src/php-4.1.0 $ type make make is hashed (/home/mdev/local/bin/make) mdev@server6 ~/_src/php-4.1.0 $ echo $MAKE /home/mdev/local/bin/make mdev@server6 ~/_src/php-4.1.0 $ make Makefile:34: *** missing separator. Stop. mdev@server6 ~/_src/php-4.1.0 $ grep 'HAVE_RES_SEARCH' ./main/php_config.h /* #undef HAVE_RES_SEARCH */ By the way - the issue with shared libs didn't apply. I did rm -rf /php/lib before I did anything else and php.ini didn't load anything it shouldn't be able to find, judging from ls and ldd. But can you ellaborate on the issues above? [2001-11-19 17:58:03] [EMAIL PROTECTED] You might be having an issue with old shared extension being loaded. Check it first. ie. try disabling the loading of such extensions in php.ini [2001-11-18 22:28:12] [EMAIL PROTECTED] Ok: BSDi 4.2 i386 with GNUmake 3.79.1, autoconf 2.13, automake 1.5, libtool 1.4, configured as: #!/bin/sh ./configure \ --prefix=/php \ --with-perl=/perl/bin/perl \ --with-apxs=/apache/bin/apxs \ --with-config-file-path=/weblib/local/lib \ --with-openssl=/weblib/local \ --disable-short-tags \ --with-zlib \ --with-zlib-dir=/weblib/local \ --enable-bcmath \ --enable-calendar \ --with-curl=shared,/weblib/local \ --with-dom=shared,/weblib/local \ --enable-ftp \ --with-gd=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-freetype-dir=/weblib/local \ --with-iconv=shared,/weblib/local \ --enable-mailparse \ --enable-mbstring \ --with-mcal=shared,/weblib/local \ --with-mcrypt=shared,/weblib/local \ --with-mhash=shared,/weblib/local \ --with-mysql=/weblib/local \ --with-pdflib=/weblib/local \ --with-jpeg-dir=/weblib/local \ --with-png-dir=/weblib/local \ --with-tiff-dir=/weblib/local \ --with-pgsql=shared,/pgsql \ --enable-sockets \ --with-expat-dir=/weblib/local \ --enable-xslt \ --with-xslt-sablot=shared,/weblib/local \ --with-expat-dir=/weblib/local \ --with-iconv-dir=/weblib/local checking for res_search... no checking for res_search in -lsocket... no checking for res_search in -lresolv... no $ grep -i 'res_search' ./main/php_config.h /* Define if you have the `res_search' function. */ /* #undef HAVE_RES_SEARCH */ This means, that getmxrr() isn't available. checking whether to enable xslt support... yes checking whether to enable the XSLT Sablotron backend... yes, shared checking libexpat dir for Sablotron XSL support... yes checking for iconv_open in -lc... no checking for SablotSetEncoding in -lsablot... yes So - that works now. make now works (always does in snapshots - not in releases). But then, apache won't start: $ gdb -core ./httpd.core -exec apache/bin/httpd GNU gdb Copyright 1998 Free Software
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Unknown/Other Function
Operating System: BSD/OS 4.x
PHP Version: 4.0.6
New Comment:
Ok:
BSDi 4.2 i386 with GNUmake 3.79.1, autoconf 2.13, automake 1.5, libtool 1.4,
configured as:
#!/bin/sh
./configure \
--prefix=/php \
--with-perl=/perl/bin/perl \
--with-apxs=/apache/bin/apxs \
--with-config-file-path=/weblib/local/lib \
--with-openssl=/weblib/local \
--disable-short-tags \
--with-zlib \
--with-zlib-dir=/weblib/local \
--enable-bcmath \
--enable-calendar \
--with-curl=shared,/weblib/local \
--with-dom=shared,/weblib/local \
--enable-ftp \
--with-gd=/weblib/local \
--with-jpeg-dir=/weblib/local \
--with-png-dir=/weblib/local \
--with-freetype-dir=/weblib/local \
--with-iconv=shared,/weblib/local \
--enable-mailparse \
--enable-mbstring \
--with-mcal=shared,/weblib/local \
--with-mcrypt=shared,/weblib/local \
--with-mhash=shared,/weblib/local \
--with-mysql=/weblib/local \
--with-pdflib=/weblib/local \
--with-jpeg-dir=/weblib/local \
--with-png-dir=/weblib/local \
--with-tiff-dir=/weblib/local \
--with-pgsql=shared,/pgsql \
--enable-sockets \
--with-expat-dir=/weblib/local \
--enable-xslt \
--with-xslt-sablot=shared,/weblib/local \
--with-expat-dir=/weblib/local \
--with-iconv-dir=/weblib/local
checking for res_search... no
checking for res_search in -lsocket... no
checking for res_search in -lresolv... no
$ grep -i 'res_search' ./main/php_config.h
/* Define if you have the `res_search' function. */
/* #undef HAVE_RES_SEARCH */
This means, that getmxrr() isn't available.
checking whether to enable xslt support... yes
checking whether to enable the XSLT Sablotron backend... yes, shared
checking libexpat dir for Sablotron XSL support... yes
checking for iconv_open in -lc... no
checking for SablotSetEncoding in -lsablot... yes
So - that works now.
make now works (always does in snapshots - not in releases).
But then, apache won't start:
$ gdb -core ./httpd.core -exec apache/bin/httpd
GNU gdb
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-bsdi4.2.
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /shlib/libdl.so...done.
Reading symbols from /shlib/libgcc.so.1...done.
Reading symbols from /shlib/libc.so.2...done.
Reading symbols from /shlib/ld-bsdi.so...done.
Reading symbols from /apache/libexec/libphp4.so...done.
Reading symbols from /weblib/local/lib/libz.so...done.
Reading symbols from /weblib/local/lib/libsablot.so.0...done.
Reading symbols from /weblib/local/lib/libiconv.so.2...done.
Reading symbols from /weblib/local/lib/libexpat.so.0...done.
Reading symbols from /weblib/local/lib/libpdf.so.1...done.
Reading symbols from /weblib/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /weblib/local/lib/libgd.so...done.
Reading symbols from /weblib/local/lib/libfreetype.so.6...done.
Reading symbols from /weblib/local/lib/libpng.so.2...done.
Reading symbols from /weblib/local/lib/libjpeg.so.62...done.
Reading symbols from /weblib/local/lib/libssl.so.0.9.6...done.
Reading symbols from /weblib/local/lib/libcrypto.so.0.9.6...done.
Reading symbols from /shlib/libm.so.0.0...done.
Reading symbols from /apache/libexec/mod_gzip.so...done.
#0 0x481f2a67 in zend_register_functions (functions=0x48301e20, function_table=0x0,
type=1) at zend_API.c:1046
1046if (zend_hash_add(target_function_table, ptr-fname,
strlen(ptr-fname)+1, function, sizeof(zend_function), NULL)
== FAILURE) {
(gdb) bt
#0 0x481f2a67 in zend_register_functions (functions=0x48301e20, function_table=0x0,
type=1) at zend_API.c:1046
#1 0x481f2bd7 in zend_register_module (module=0x48301ea4) at zend_API.c:1099
#2 0x481f29c2 in zend_startup_module (module=0x48301ea4) at zend_API.c:1010
#3 0x481fcf14 in php_startup_extensions (ptr=0x482f8230, count=17) at main.c:780
#4 0x481fe333 in php_startup_internal_extensions () at internal_functions.c:78
#5 0x481fd3a5 in php_module_startup (sf=0x482f709c) at main.c:935
#6 0x481fa4b6 in php_apache_startup (sapi_module=0x482f709c) at mod_php4.c:279
#7 0x481fadb1 in php_apache_value_handler_ex (cmd=0x8047b0c, conf=0x812a2c0,
arg1=0x8149284 include_path,
arg2=0x8149294
[PHP-DEV] Bug #14048: Configure issues
From: [EMAIL PROTECTED]
Operating system: BSD/OS 4.x
PHP version: 4.0.6
PHP Bug Type: Unknown/Other Function
Bug description: Configure issues
Hi,
for a number of releases I've dealt with some known issues, but felt it's
time to summarize them here, since I think I've pretty much got them all,
including the fixes.
1) Native make + gnu make
For some reason, php is the only package, that manages to override the
variable MAKE=/path/to/make as well as the make in the PATH setting. If you
keep the native make (which is sensible, for it's best used for creating a
new kernel), but you have your own make compiled in your own dirs, then
make doesn't work. The reason is, the old include format. I use this
perlscript 'makefix.pl' to fix the issues:
#!/perl/bin/perl
use Getopt::Long;
my $dir=$ENV{'HOME'}.'/_src/php-4.0.4pl1';
GetOptions(
'dir=s' = \$dir);
chdir($dir) || die Can't change to $dir\n$!\n;
open(FILE, './makefix.lst') || die Please create the list first,
with:\nfind -x . -exec grep -l -E '\\.include \\\' {} \\;
./makefix.lst;
@files = FILE;
close(FILE);
for $i (0..$#files) {
$fix = $files[$i];
next if $fix =~ /\.bak$/;
chomp($fix);
$bak = $fix . '.bak';
system(cp $fix $bak);
print STDOUT Trying $bak and $fix;
open(BAK, $bak) || die cant open $bak\n$!\n;
open(FIX, $fix) || die cant open $fix\n$!\n;
while(BAK) {
chomp;
s/^\.include \([^\]+)\\s?$/include $1/;
print FIX $_;
print FIX \n;
}
close(BAK);
close(FIX);
print STDOUT fixed.\n;
}
exit(0);
It can probably be done more easily, but it works.
2) INET_* functions
Are native for BSDi and don't need a library. Secondly, they complain
without the right headers. Here's a snippet from the Bind configure script,
on how to _correctly_ test for these functions:
echo $ac_n checking for inet_aton... $ac_c 16
echo configure:3901: checking for inet_aton 5
cat conftest.$ac_ext EOF
#line 3903 configure
#include confdefs.h
#include sys/types.h
#include netinet/in.h
#include arpa/inet.h
int main() {
struct in_addr in; inet_aton(0, in); return (0);
; return 0; }
EOF
The native bind on BSDi does have __inet_aton in libbind, but it's static,
so PHP complains and you need to edit config.h and Zend/Makefile to get rid
of it.
Secondly - bind 9.x requires not only libbind but libisc as well, so any
tests for -lbind will always fail, if you've upgraded your named package.
3) res_search
Is also native on BSDi. I don't have a definite fix, since I'm no
C-programmer, but I just add these lines to the end of main/php_config.h.in
to work around it:
#ifdef __bsdi__
#define HAVE_RES_SEARCH 1
#endif
man 3 res_search says:
DEPRECATED
#include sys/types.h
#include netinet/in.h
#include arpa/nameser.h
#include resolv.h
...
res_search(const char *dname, int class, type, u_char *answer, int
anslen);
4) Iconv and XSLT
Below is a typical diff for any section in configure trying to find iconv
for the XSLT section:
found_iconv=no
! echo $ac_n checking for iconv_open in -lc... $ac_c 16
! echo configure:48789: checking for iconv_open in -lc 5
ac_lib_var=`echo c'_'iconv_open | sed 'y%./+-%__p_%'`
if eval test \`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\ = set;
then
echo $ac_n (cached) $ac_c 16
else
ac_save_LIBS=$LIBS
! LIBS=-lc $LIBS
cat conftest.$ac_ext EOF
#line 48797 configure
#include confdefs.h
--- 48784,48797
found_iconv=no
! echo $ac_n checking for iconv_open in -liconv... $ac_c 16
! echo configure:48789: checking for iconv_open in -liconv 5
ac_lib_var=`echo c'_'iconv_open | sed 'y%./+-%__p_%'`
if eval test \`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\ = set;
then
echo $ac_n (cached) $ac_c 16
else
ac_save_LIBS=$LIBS
! LIBS=-liconv $LIBS
cat conftest.$ac_ext EOF
#line 48797 configure
#include confdefs.h
It will do this correctly for --with-iconv, but later on when iconv is
specified with xslt, it breaks. There are several sections in the configure
script and I usually fix them all just to spare me the havoc of find out
which is called and why.
I hope you can address these issues before 4.0.7 release.
As a side note:
The latest snapshots work correctly with make as always, but then the
release versions don't.
--
Edit bug report at: http://bugs.php.net/?id=14048edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11892 Updated: crypt gone without a trace
ID: 11892
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Encryption and hash functions
Operating System: BSD
PHP Version: 4.0.6
New Comment:
Crypt failes because libcrypt is searched for. This isn't necessary on BSD systems,
because it's part of libc. So, this simple conftest.c below, will already work:
int main()
{
char *pw, salt[3];
extern char *crypt(const char *, const char *);
crypt(pw, salt);
return 1;
}
please incorporate this in the configure script and set HAVE_CRYPT in
main/php_config.h accordingly.
People using php on these systems, simply edit main/php_config.h and change /* #undef
HAVE_CRYPT */ to #define HAVE_CRYPT 1 in the appropriate place.
Previous Comments:
[2001-07-04 19:26:14] [EMAIL PROTECTED]
Any call to crypt() creates an empty string. Downgrade to 4.0.5 fixes the problem.
I also tried putting the '4.0.5' crypt.c in the '4.0.6' build and recompiled after a
make clean, but that didn't make a difference.
Edit this bug report at http://bugs.php.net/?id=11892edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11892: crypt gone without a trace
From: [EMAIL PROTECTED] Operating system: BSD PHP version: 4.0.6 PHP Bug Type: *Encryption and hash functions Bug description: crypt gone without a trace Any call to crypt() creates an empty string. Downgrade to 4.0.5 fixes the problem. I also tried putting the '4.0.5' crypt.c in the '4.0.6' build and recompiled after a make clean, but that didn't make a difference. -- Edit Bug report at: http://bugs.php.net/?id=11892edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
