#21978 [Fbk->Opn]: bbc: send twice
ID: 21978 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Mail Related Operating System: Windows 2000 Server PHP Version: 4CVS-2003-01-31 (stable) New Comment: These are the arguments I pass to mail() function : $headers = "MIME-Version: 1.0"; $headers .= "Content-type: text/html; charset=iso-8859-1\r\n"; $headers .= "From: SWZone Newsletter <[EMAIL PROTECTED]>\r\n"; $headers .= "Bcc: [EMAIL PROTECTED],\r\n"; $headers .= "Reply-To: SWZone Newsletter <[EMAIL PROTECTED]>\r\n"; $headers .= "X-Priority: 3\r\n"; $headers .= "X-MSMail-Priority: Normal\r\n"; $headers .= "X-Mailer: SWZ Mail Server\r\n"; $to = "[EMAIL PROTECTED]"; $message="ciao"; mail($to, $subject, "$message", $headers); Previous Comments: [2003-01-31 17:50:02] [EMAIL PROTECTED] What are the arguments that you are passing to the mail() function? [2003-01-31 05:32:20] [EMAIL PROTECTED] I have got the same problem repoted here #21036 I'm using the last CVS of 31-01-03 but still have problem. When I use bbc field, php send mail twice to the recipient, this don't happen in to: and cc: recipent field. Here the debug of my mail server : 01/31/03 12:16:46 ID 1732 - HELO WWWSWZ\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ ( IP: 127.0.0.1 ) has connected to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - MAIL FROM:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - [EMAIL PROTECTED] is sending a message to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - DATA\0D\0A 01/31/03 12:16:46 ID 1732 - 354 Start mail input; end with .\0D\0A 01/31/03 12:16:46 ID 1732 - Date: Fri, 31 Jan 2003 12:16:46 +0100\0D\0A 01/31/03 12:16:46 ID 1732 - From: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - Subject: La Newsletter di Software Zone Italia\0D\0A 01/31/03 12:16:46 ID 1732 - To: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - MIME-Version: 1.0Content-type: text/html; charset\3Diso-8859-1\0D\0A 01/31/03 12:16:46 ID 1732 - \0D\0A 01/31/03 12:16:46 ID 1732 - ciao\0D\0A 01/31/03 12:16:46 ID 1732 - .\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - QUIT\0D\0A 01/31/03 12:16:46 ID 1732 - 221 Service closing transmission channel\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ has finished delivering messages to the mail server A message to the address bcc: [EMAIL PROTECTED] has been sent twice. -- Edit this bug report at http://bugs.php.net/?id=21978&edit=1
#21973 [Fbk->Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: > Anyway, in what version of PHP did LDAP configure > work without any patches? The CVS tag is php_4_3_0pre2. I've done a fresh checkout with that tag and can verify that the 'configure' script generated by my copies of autoconf, etc, works. I tried the following successful combinations: - autoconf 2.52, automake 1.5, libtool 1.4 - autoconf 2.57, automake 1.7.2, libtool 1.4.3 - flex 2.5.4 and bison 1.75 were used in all cases. Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using Sun's CCS assembler Sun's CCS linker (typical scenario). Notes: - first, I applied my int/long correctness patches (fortunately, these do not influence the configure step). - ldap configures and compiles with no warnings or errors. BUT I have to induce -lldap myself (other modules, such as database modules, seem to pick up their libraries okay, though). So really, ldap configuration wasn't entirely working in pre2 but the fault had a different manifestation than in the release, and had obvious output/cause/workaround. - the gd module configures with errors but I commented out the 'exit' commands and configure completes. - the ldap and gd modules then appear work fine with Apache. - I had to comment out _LT_AC_TRY_DLOPEN_SELF when using the second lot of auto tools. But when I do a buildconf, configure, make with php_4_3_0, I get the problem "Cannot find ldap libraries in $LDAP_LIBDIR." Notes: - first, I applied my int/long correctness patches (fortunately, these do not influence the configure step). - I can work around the gd & ldap problems by manually deleting the 'exit' commands in the configure script or inserting the sparcv9 path element into the configure script, in which case the ldap module then picks up -lldap by itself. - the _LT_AC_TRY_DLOPEN_SELF problem has disappeared in 4.3.0 release. - the ldap and gd modules then appear work fine with Apache. > Is the only problem really that we check that the actual > library _file_ exists? Better way of course would be to > use PHP_CHECK_LIBRARY macro always and not do the > filesystem checks at all, like Marcus suggested..? Yes, in my understanding. Previous Comments: [2003-01-31 07:55:59] [EMAIL PROTECTED] I misunderstood the problem apparently, sorry for that. Anyway, in what version of PHP did LDAP configure work without any patches? Is the only problem really that we check that the actual library _file_ exists? Better way of course would be to use PHP_CHECK_LIBRARY macro always and not do the filesystem checks at all, like Marcus suggested..? [2003-01-31 06:19:33] [EMAIL PROTECTED] > we would have to change all configure files. Maybe huge rafts of PHP use the lib name convention, but for some reason it doesn't matter -- those parts of PHP work in my context anyway. And yes, some modules compile and some don't. Some used to and now they don't. >From my point of view: A) Why it would be okay that a module like ldap worked two/three months ago but does not configure correctly today. Surely this would considered to be regression. B) Why other software doesn't stumble during configuration but PHP does. Surely this is a problem with PHP. Maybe it's a case of "gosh, this is extensively wrong", but that doesn't make the problem bogus. C) I suspect that PHP would compile and run correctly if I comment out the 'exit' commands in configure. Then, if the ONLY reason that PHP doesn't compile is that configure stumbles -- not that any libraries are missing or can't already be found by the compiler -- surely that is because the implementation of 'configure' is wrong. It's as though...configure doesn't need to be made to work differently in as much as it may be sufficient if it just stopped exiting prematurely. After doing some experimentation with this, maybe I have to resubmit this bug for each affected module? Gah. Alternatively, maybe I can post to php-dev and an existing developer can pick up this matter in general (which is what I'd hoped would happen with this report)? [2003-01-31 05:28:14] [EMAIL PROTECTED] If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9).
#21804 [Opn->Bgs]: php crashes iPlanet - php4_execute
ID: 21804 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Solaris 8 PHP Version: 4.3.1-dev New Comment: I finally had time to rectify my ignorance of threads and ran a test. Threads do share environment variables, so putenv is inherently not thread-safe. Nevermind. Previous Comments: [2003-01-31 01:10:19] [EMAIL PROTECTED] I've had more time to look into this, and found that the script below will recreate the crash. Still using http_load -parallel 5, of course. Oh, and I noticed that I accidentally posted the 4.2.3 bt here. I'll post the 4.3.1-dev bt tomorrow. Thanks [2003-01-29 16:17:37] [EMAIL PROTECTED] Bug #21948 is a bit different. The crash we get is always in strlen, and only occurs under load when we set environment variables in the script. It sounds like #21948 happens every time, not just under load. My naive WAG is that the load causes a resource starvation that php does not catch. Thus a segv. But somehow this is related to environment variables. Hmm... Perhaps a bug in the section that allocates memory for env vars? Thanks [2003-01-29 15:10:45] [EMAIL PROTECTED] Bug #21948 may be a related issue. [2003-01-23 13:08:56] [EMAIL PROTECTED] It crashes with other scripts as well. Our developers experienced this problem, and I found that these two scripts reliably reproduce it. We set the Oracle variables in the script because multiple applications run in one web server instance - they may not use the same version of Oracle, and they certainly use different sids. However, when I commented out the putenv/getenv statements, the test ran cleanly. The "byte count wrong" messages went away too. So we do have a kludge of a work-around. It would be nice to have this fixed. I'm not clear why setting environment variables in the php script is a bad idea. I would expect each thread to have it's own environment... Thanks, David [2003-01-22 21:58:58] [EMAIL PROTECTED] Does the crash happen only with the provided script? And btw. you should set those envinronment variables in the system, NOT in the script.. 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/21804 -- Edit this bug report at http://bugs.php.net/?id=21804&edit=1
#21992 [NEW]: snmpget returns wrong value on negative integer
From: [EMAIL PROTECTED] Operating system: Windows XP Pro SP1 PHP version: 4CVS-2003-01-31 (stable) PHP Bug Type: SNMP related Bug description: snmpget returns wrong value on negative integer I believe i read somewhere that PHP's integer max was 2147483647? If using snmp to pull bandwidth information from a device (such as ifInOctets and ifOutOctets), the number DOES constandly rise. If using a device with snmpv1 (32bit) the counter will only reach a certain number before it rolls over the the opposite and negative number and counts toward the maximum again. The Max (and prolly min?) is the same as PHP's. "INTEGER(-2147483648..2147483647) -- corresponds to a signed 32-bit int" Well, once the counter turns over to the negative, php only returns "2147483647" for every negative value it reads. Such as, my ifInOctets for my cisco router is now reading '-1980181848', and php's snmpget on that oid returns '2147483647', but when the counter is positive, it returns the correct value. (this is probably a problem on 64bit snmpv2 since i believe its maximum is much higher, but thats probably not fix-able) -- Edit bug report at http://bugs.php.net/?id=21992&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21992&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21992&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21992&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21992&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21992&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21992&r=support Expected behavior: http://bugs.php.net/fix.php?id=21992&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21992&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21992&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21992&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21992&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21992&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21992&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21992&r=gnused
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: All PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable) New Comment: Have Apache/2.0.44 (RedHat8.0 (LastUpdates) mod_ssl/2.0.44 OpenSSL/0.9.6b PHP/4.3.0 Starting Apache answers - [root@delta bin]# httpd -DSSL httpd: module "/usr/src/php-4.3.0/sapi/apache2filter/sapi_apache2.c" is not comp atible with this version of Apache. Please contact the vendor for the correct version. Where troubles ? Previous Comments: [2003-01-30 03:52:45] [EMAIL PROTECTED] [EMAIL PROTECTED], Thank you for the info! Okay, updating version. [2003-01-30 03:46:38] [EMAIL PROTECTED] Not a single 'BUG' entry on the logs, grep'ed all of them. [2003-01-30 03:45:41] [EMAIL PROTECTED] Tested today with snapshot 5-200301291430: post duplication bug continues. I believe the bug is really a matter of duplication of the post: simple vars are overriden, arrays get duplicated, raw data gets duplicated. [2003-01-30 03:25:04] [EMAIL PROTECTED] I'm not sure, but I guess this problem is caused by the bug gy Apache2 filter code. Is there anyone who found some strange entries that begin with "* BUG *" in the error logs when running the server with the latest snapshot of PHP? [2003-01-29 10:01:27] [EMAIL PROTECTED] when you post raw data it gets duplicated too, but it's not constant: on two hosts with rh8/4.2.2 (and 4.3.0 tested as well) only one seems to do the duplication. The one that duplicates has an up2dated httpd, so apache version might have something to do with it. 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648&edit=1
#21946 [Opn->Bgs]: Trying to create COM object - Apache crash
ID: 21946
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: Windows NT 4.0, Service pack 6a
PHP Version: 4.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
and fixed in cvs !
Read the instructions at http://bugs.php.net/how-to-report.php before
filing a bugreport or i'll let the crazy finn loose :)
Previous Comments:
[2003-01-30 08:55:43] [EMAIL PROTECTED]
I managed to do it using ActivePerl - working fine.
Best regards,
Dominik
[2003-01-30 03:37:15] [EMAIL PROTECTED]
The latest stable did not solved my issue. The error is :
The instruction at "0x007205f9" refrenced memory at "0x5e3019c0". The
memory
could not be "read".
Best regards,
Dominik
[2003-01-30 01:42:15] [EMAIL PROTECTED]
I had this same issue on Win2k Pro running Apache 3.1.26.
I have other php scripts that were running fine. Only the one with COM
was blowing up.
Application popup: Apache.exe - Application Error : The instruction at
"0x10030727" referenced memory at "0x04243b30". The memory could not be
"read".
The latest stable release solved my issue. Thanks!
[2003-01-29 18:26:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-29 15:03:55] [EMAIL PROTECTED]
Original lines from ASP :
Q= Server.CreateObject("ixsso.Query");
util = Server.CreateObject("ixsso.Util");
Q.Query = "test";
Q.Columns = "DocTitle, Vpath, filename, size, write,
characterization, rank, path, DocSubject, DocKeywords";
RS = Q.CreateRecordSet("nonsequential");
but as I said I have commented all the lines after first line. I have
read in some forum that someone did succeed to integrate PHP with
Microsoft Index Server.
Best regards,
Dominik
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/21946
--
Edit this bug report at http://bugs.php.net/?id=21946&edit=1
#21947 [Fbk]: Issues with OpenSSL v.0.9.7
ID: 21947
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: OpenSSL related
Operating System: RedHat 8.0
PHP Version: 4.3.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Some issues were just fixed.
Previous Comments:
[2003-01-29 12:06:10] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2003-01-29 11:54:18] [EMAIL PROTECTED]
After configuring PHP.4.3.0 with the newest version of OpenSSL.0.9.7
Apache 2.0.44 will fail to start due to a undefined variable in
libphp4.so.
This is reproducable on 3 different machines.
switch used for configure:
./configure --with-ssl=/usr/local/ssl/ {...}
/usr/local/ssl is where openssl.0.9.7 is installed
--
Edit this bug report at http://bugs.php.net/?id=21947&edit=1
#21953 [Csd->Bgs]: $_session looses type
ID: 21953 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Session related Operating System: linux PHP Version: 4.3.0 New Comment: as you wish. Previous Comments: [2003-01-31 15:09:09] [EMAIL PROTECTED] Sorry this is bogus. I don't know what happened, but now it works as expected. [2003-01-31 04:35:07] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-29 15:34:37] [EMAIL PROTECTED] The following snippet: $bunch=10; $_SESSION['mail'] = (int)$_SESSION['mail'] + $bunch; only works with the (int) in front of $_session. Otherwise get "unsupported operand types" error. This is mysterious, Session control in PHP should preserve type. Typical Session file was as follows: mail|i:-1;Mail_title|s:4:"test";Mail_body|s:4:"test"; you see mail was of type i. -- Edit this bug report at http://bugs.php.net/?id=21953&edit=1
#21966 [Opn->Bgs]: date() or mktime() returning bad value for mktime month param of '2'
ID: 21966
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Gentoo Linux 1.4
PHP Version: 4.2.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Reason explained in previous comment.
Previous Comments:
[2003-01-30 13:26:11] [EMAIL PROTECTED]
See what you get if you use the "r" format:
# php -r 'for($x=1; $x<=3; $x++) {
echo "$x = ".date("r", mktime(0,0,0,$x))."\n"; }'
1 = Thu, 30 Jan 2003 00:00:00 +0100
2 = Sun, 2 Mar 2003 00:00:00 +0100
3 = Sun, 30 Mar 2003 00:00:00 +0100
So apparently the "February, 30th" is turned into its normal
representation by mktime(). Although that doesn't seem to be
documented, I think that's a feature, because it helps doing date
calculations.
[2003-01-30 12:40:30] [EMAIL PROTECTED]
#!/usr/bin/php -q
1 = 01
2 = 03
3 = 03
4 = 04
5 = 05
6 = 06
7 = 07
8 = 08
9 = 09
10 = 10
11 = 11
12 = 12
--
Edit this bug report at http://bugs.php.net/?id=21966&edit=1
#21991 [Fbk]: CLI only gets compiled with --with-apxs
ID: 21991
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Configuration Issues
Operating System: Debian GNU/Linux Sid/Unstable
PHP Version: 4.3.0
New Comment:
Please read these docs:
http://www.php.net/features.commandline
And clarify if you meant cli isn't being built at all (as
sapi/cli/php) or if you mean 'make install' isn't putting cli in
{prefix}/bin/php because after reading those docs you will realize that
you need 'make install-cli' under certain conditions to put it there.
Those docs will explain this confusing issue.
Previous Comments:
[2003-01-31 17:27:48] [EMAIL PROTECTED]
If you want cli only you should probably just add --disable-cgi as it
is cgi that is installed by default when both cgi and cli are
selected.
[2003-01-31 17:19:24] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Seems you must have done something more. I tried it myself
and it is working. However i did it with current CVS version. Could you
please try that yourself?
If the CVS version behaves the same way i suggest you post your
configure line here and it may be necessary to inquire the generated
makefile.
However there is another solution for that effect: Did you use
--disable-all or --disable-cli for any reason? You can verify that by
locking into config.nice.
[2003-01-31 16:47:39] [EMAIL PROTECTED]
There seems to be a configure bug with php 4.3.0.
When you compile, you dont get the CLI unless you include --with-apxs
in the ./configure line.
I confirmed this by having my mates try out different configure lines,
they too only got it when configuring with the --with-apxs option
enabled.
If this is a global bug I do not know, but it would seem so - One of
them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian
Sid/Unstable.
--
Edit this bug report at http://bugs.php.net/?id=21991&edit=1
#21978 [Opn->Fbk]: bbc: send twice
ID: 21978 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Mail Related Operating System: Windows 2000 Server PHP Version: 4CVS-2003-01-31 (stable) New Comment: What are the arguments that you are passing to the mail() function? Previous Comments: [2003-01-31 05:32:20] [EMAIL PROTECTED] I have got the same problem repoted here #21036 I'm using the last CVS of 31-01-03 but still have problem. When I use bbc field, php send mail twice to the recipient, this don't happen in to: and cc: recipent field. Here the debug of my mail server : 01/31/03 12:16:46 ID 1732 - HELO WWWSWZ\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ ( IP: 127.0.0.1 ) has connected to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - MAIL FROM:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - [EMAIL PROTECTED] is sending a message to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - DATA\0D\0A 01/31/03 12:16:46 ID 1732 - 354 Start mail input; end with .\0D\0A 01/31/03 12:16:46 ID 1732 - Date: Fri, 31 Jan 2003 12:16:46 +0100\0D\0A 01/31/03 12:16:46 ID 1732 - From: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - Subject: La Newsletter di Software Zone Italia\0D\0A 01/31/03 12:16:46 ID 1732 - To: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - MIME-Version: 1.0Content-type: text/html; charset\3Diso-8859-1\0D\0A 01/31/03 12:16:46 ID 1732 - \0D\0A 01/31/03 12:16:46 ID 1732 - ciao\0D\0A 01/31/03 12:16:46 ID 1732 - .\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - QUIT\0D\0A 01/31/03 12:16:46 ID 1732 - 221 Service closing transmission channel\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ has finished delivering messages to the mail server A message to the address bcc: [EMAIL PROTECTED] has been sent twice. -- Edit this bug report at http://bugs.php.net/?id=21978&edit=1
#21991 [Fbk]: CLI only gets compiled with --with-apxs
ID: 21991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Configuration Issues Operating System: Debian GNU/Linux Sid/Unstable PHP Version: 4.3.0 New Comment: If you want cli only you should probably just add --disable-cgi as it is cgi that is installed by default when both cgi and cli are selected. Previous Comments: [2003-01-31 17:19:24] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Seems you must have done something more. I tried it myself and it is working. However i did it with current CVS version. Could you please try that yourself? If the CVS version behaves the same way i suggest you post your configure line here and it may be necessary to inquire the generated makefile. However there is another solution for that effect: Did you use --disable-all or --disable-cli for any reason? You can verify that by locking into config.nice. [2003-01-31 16:47:39] [EMAIL PROTECTED] There seems to be a configure bug with php 4.3.0. When you compile, you dont get the CLI unless you include --with-apxs in the ./configure line. I confirmed this by having my mates try out different configure lines, they too only got it when configuring with the --with-apxs option enabled. If this is a global bug I do not know, but it would seem so - One of them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian Sid/Unstable. -- Edit this bug report at http://bugs.php.net/?id=21991&edit=1
#21991 [Opn->Fbk]: CLI only gets compiled with --with-apxs
ID: 21991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Debian GNU/Linux Sid/Unstable PHP Version: 4.3.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Seems you must have done something more. I tried it myself and it is working. However i did it with current CVS version. Could you please try that yourself? If the CVS version behaves the same way i suggest you post your configure line here and it may be necessary to inquire the generated makefile. However there is another solution for that effect: Did you use --disable-all or --disable-cli for any reason? You can verify that by locking into config.nice. Previous Comments: [2003-01-31 16:47:39] [EMAIL PROTECTED] There seems to be a configure bug with php 4.3.0. When you compile, you dont get the CLI unless you include --with-apxs in the ./configure line. I confirmed this by having my mates try out different configure lines, they too only got it when configuring with the --with-apxs option enabled. If this is a global bug I do not know, but it would seem so - One of them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian Sid/Unstable. -- Edit this bug report at http://bugs.php.net/?id=21991&edit=1
#21991 [NEW]: CLI only gets compiled with --with-apxs
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux Sid/Unstable PHP version: 4.3.0 PHP Bug Type: *Configuration Issues Bug description: CLI only gets compiled with --with-apxs There seems to be a configure bug with php 4.3.0. When you compile, you dont get the CLI unless you include --with-apxs in the ./configure line. I confirmed this by having my mates try out different configure lines, they too only got it when configuring with the --with-apxs option enabled. If this is a global bug I do not know, but it would seem so - One of them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian Sid/Unstable. -- Edit bug report at http://bugs.php.net/?id=21991&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21991&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21991&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21991&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21991&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21991&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21991&r=support Expected behavior: http://bugs.php.net/fix.php?id=21991&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21991&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21991&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21991&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21991&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21991&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21991&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21991&r=gnused
#21987 [Opn->Bgs]: segfault
ID: 21987 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Openbsd 3.2 PHP Version: 4.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Given the provided information there is nothing to indicate that it is PHP who is responsible for the broken configuration. If you want you could try compiling PHP with --enable-debug, which may make the backtrace more meaningful if it is indeed PHP who is responsible for the problem. Previous Comments: [2003-01-31 13:39:00] [EMAIL PROTECTED] after compiling the new php 4.3.0 using (leaving my old apache alone) ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql --with-openssl --with-gettext --with-xml --with-imap --with-imap-ssl --with-mcrypt --with-zlib then restart time: [root@amanda /home/quel/php-4.3.0] /usr/local/apache/bin/apachectl restart /usr/local/apache/bin/apachectl restart: configuration broken, ignoring restart /usr/local/apache/bin/apachectl restart: (run 'apachectl configtest' for details) [root@amanda /home/quel/php-4.3.0] /usr/local/apache/bin/apachectl configtest Memory fault (core dumped) [root@amanda /home/quel/php-4.3.0] gdb /usr/local/apache/bin/httpd httpd.core #0 0x4019e33a in strcmp () (gdb) bt #0 0x4019e33a in strcmp () #1 0xb380e in obj_name_cmp () bt seems useless and incomplete to me... I once had this problem when getting php 4.2.3 up, however bt showed issues in libc and the problem was related to the --with-kerberos option (which i didn't use this time around) [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21987&edit=1
#21854 [Opn]: Output compression stops working
ID: 21854 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zlib Related Operating System: Redhat 7.2 PHP Version: 4.3.0 New Comment: As a test i downgraded to 4.2.3 and it does NOT have this issue. Previous Comments: [2003-01-31 16:20:15] [EMAIL PROTECTED] Since i was running zlib 1.1.3 i updated it to 1.1.4 and it and i am still having the same issue. [2003-01-30 02:55:09] [EMAIL PROTECTED] i used php.ini-recommended. and changed zlib ompression and some error directives. my system: rh 7.2 php 4.3.0 apache 1.2.37 zlib 1.1.4 [2003-01-29 15:11:34] [EMAIL PROTECTED] I tried using both .ini files the php.ini-dist and the php.ini-recommended changing only the zlib.output_compression setting and still have the same issue. [2003-01-29 11:38:25] [EMAIL PROTECTED] tux witch ini file did you use the php.ini-dist or the php.ini-recommended? [2003-01-29 07:43:13] [EMAIL PROTECTED] i had the same problem, but after the php.ini update, everything worked fine... tnx sniper... 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/21854 -- Edit this bug report at http://bugs.php.net/?id=21854&edit=1
#21854 [Opn]: Output compression stops working
ID: 21854 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zlib Related Operating System: Redhat 7.2 PHP Version: 4.3.0 New Comment: Since i was running zlib 1.1.3 i updated it to 1.1.4 and it and i am still having the same issue. Previous Comments: [2003-01-30 02:55:09] [EMAIL PROTECTED] i used php.ini-recommended. and changed zlib ompression and some error directives. my system: rh 7.2 php 4.3.0 apache 1.2.37 zlib 1.1.4 [2003-01-29 15:11:34] [EMAIL PROTECTED] I tried using both .ini files the php.ini-dist and the php.ini-recommended changing only the zlib.output_compression setting and still have the same issue. [2003-01-29 11:38:25] [EMAIL PROTECTED] tux witch ini file did you use the php.ini-dist or the php.ini-recommended? [2003-01-29 07:43:13] [EMAIL PROTECTED] i had the same problem, but after the php.ini update, everything worked fine... tnx sniper... [2003-01-29 01:07:09] [EMAIL PROTECTED] My ini file was quit differnt i belive it was from a older version so i copied over the new one and changed only the zlib.output_compression setting below is the diff --- php.ini-recommended Thu Dec 26 08:07:59 2002 +++ /usr/local/lib/php.ini Wed Jan 29 01:03:00 2003 @@ -127,7 +127,7 @@ ; also. ; Note: output_handler must be empty if this is set 'On' ; Instead you must use zlib.output_handler. -zlib.output_compression = Off +zlib.output_compression = On ; You cannot specify additional output handlers if zlib.output_compression ; is activated here. This setting does the same as output_handler but in /usr/local/apache/bin/httpd -X Doing this it still fails only takes about 1 refresh and it's dead. 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/21854 -- Edit this bug report at http://bugs.php.net/?id=21854&edit=1
#21986 [Asn->Csd]: Apache won't start with libphp4.so compiled with OpenSSl 0.9.7
ID: 21986 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: OpenSSL related Operating System: FreeBSD 4.6.2 PHP Version: 4.3.0 Assigned To: iliaa New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-31 13:02:36] [EMAIL PROTECTED] Apache 1.3.27 with modssl 2.8.12: OpenSSL 0.9.7 Returns an error something like: "Undefined symbol OpenSSL_..._noconf" php4.3.0 configured with the following line: './configure' '--with-mysql=/usr/local/mysql' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-track-vars' '--with-pdflib' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--enable-gd-native-ttf' '--with-png-dir=/usr/local/lib' '--with-xpm-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-ttf' '--with-tiff-dir' '--with-zlib' '--enable-ftp' '--enable-cli' '--with-pspell' --with-openssl This bug is similar to bug #21947 it seems that there might be a problem with openSSL 0.9.7 and php 4.3.0 together make test returned 2 FAILS (previously none with openssl 0.9.6e) 1. Fail on error handling 2. Fail on Open SSL create keys (or something like that) Thanks for help and support Peter -- Edit this bug report at http://bugs.php.net/?id=21986&edit=1
#21990 [NEW]: switch() compare using ===
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: Feature/Change Request Bug description: switch() compare using === Hi, I was doing some developing and noticed that switch() only does a == compare and not a === compare (e.g. case -7:). I would like to request it (if it's not aleady done). Thank you for your time. -- Edit bug report at http://bugs.php.net/?id=21990&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21990&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21990&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21990&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21990&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21990&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21990&r=support Expected behavior: http://bugs.php.net/fix.php?id=21990&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21990&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21990&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21990&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21990&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21990&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21990&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21990&r=gnused
#21988 [Opn->Csd]: macro replacement with streams
ID: 21988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Warning Operating System: sco openserver PHP Version: 4.3.0 New Comment: fixed in latest CVS Previous Comments: [2003-01-31 13:39:45] [EMAIL PROTECTED] php-4.3.0/main/php_streams.h, line 321: warning: no macro replacement within a string literal php-4.3.0/main/php_streams.h, line 322: warning: no macro replacement within a string literal -- Edit this bug report at http://bugs.php.net/?id=21988&edit=1
#21986 [Opn->Asn]: Apache won't start with libphp4.so compiled with OpenSSl 0.9.7
ID: 21986 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: FreeBSD 4.6.2 PHP Version: 4.3.0 -Assigned To: +Assigned To: iliaa Previous Comments: [2003-01-31 13:02:36] [EMAIL PROTECTED] Apache 1.3.27 with modssl 2.8.12: OpenSSL 0.9.7 Returns an error something like: "Undefined symbol OpenSSL_..._noconf" php4.3.0 configured with the following line: './configure' '--with-mysql=/usr/local/mysql' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-track-vars' '--with-pdflib' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--enable-gd-native-ttf' '--with-png-dir=/usr/local/lib' '--with-xpm-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-ttf' '--with-tiff-dir' '--with-zlib' '--enable-ftp' '--enable-cli' '--with-pspell' --with-openssl This bug is similar to bug #21947 it seems that there might be a problem with openSSL 0.9.7 and php 4.3.0 together make test returned 2 FAILS (previously none with openssl 0.9.6e) 1. Fail on error handling 2. Fail on Open SSL create keys (or something like that) Thanks for help and support Peter -- Edit this bug report at http://bugs.php.net/?id=21986&edit=1
#21989 [Opn->Asn]: openssl_csr_new causes apache+modphp to segfault
ID: 21989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Linux x86 (2.4.x, glibc 2.3) PHP Version: 4.3.0 -Assigned To: +Assigned To: iliaa Previous Comments: [2003-01-31 13:58:34] [EMAIL PROTECTED] When php 4.3.0 is compiled as loaded as an apache module (apache 1.3.27 from Debian Linux) accessing the function openssl_csr_new causes apache to segfault. Building php as a CGI this apparently does not happen (but I've not investigated this all that closely). Attaching to the apache process (where modphp has been build with symbols) shows the actual segfault occurs inside php_openssl_make_REQ (no stack trace available as I guess something get's clobbered and messes this up). Placing a breakpoint at php_openssl_make_REQ I see it is entered with a stack of: Breakpoint 2, php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1143 1143STACK_OF(CONF_VALUE) * dn_sk, *attr_sk = NULL; (gdb) bt #0 php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1143 #1 0x403a8429 in zif_openssl_csr_new (ht=2, return_value=0x81163ec, this_ptr=0x0, return_value_used=1) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1583 #2 0x404adf62 in execute (op_array=0x811333c) at /home/cw/wk/zaphod/php4/php4-4.3.0/Zend/zend_execute.c:1596 #3 0x4049af24 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cw/wk/zaphod/php4/php4-4.3.0/Zend/zend.c:864 #4 0x4045fd53 in php_execute_script (primary_file=0xb764) at /home/cw/wk/zaphod/php4/php4-4.3.0/main/main.c:1573 #5 0x404b3470 in apache_php_module_main (r=0x8109564, display_source_mode=0) at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/sapi_apache.c:55 #6 0x404b4410 in send_php (r=0x8109564, display_source_mode=0, filename=0x810b0dc "/var/www/other.php") at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/mod_php4.c:556 #7 0x404b448f in send_parsed_php (r=0x8109564) at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/mod_php4.c:571 #8 0x08053b34 in ap_invoke_handler () #9 0x0806368c in ap_some_auth_required () #10 0x080636e8 in ap_process_request () #11 0x0805ce2b in ap_child_terminate () #12 0x0805cfbc in ap_child_terminate () #13 0x0805d0d9 in ap_child_terminate () #14 0x0805d5b5 in ap_child_terminate () #15 0x0805dcbd in main () #16 0x400e59f1 in __libc_start_main () from /lib/libc.so.6 and then dies at php4-4.3.0/ext/openssl/openssl.c line 1185 (the call to X509_NAME_add_entry_by_NID): Breakpoint 4, php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1185 1185if (!X509_NAME_add_entry_by_NID(subj, nid, MBSTRING_ASC, (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x402c6f8b in sk_value () from /usr/lib/i686/cmov/libcrypto.so.0.9.6 (gdb) I don't know enough about this call, php or indeed anything to really know what variables to poke and look at further. -- Edit this bug report at http://bugs.php.net/?id=21989&edit=1
#21953 [Fbk->Csd]: $_session looses type
ID: 21953 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Session related Operating System: linux PHP Version: 4.3.0 New Comment: Sorry this is bogus. I don't know what happened, but now it works as expected. Previous Comments: [2003-01-31 04:35:07] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-29 15:34:37] [EMAIL PROTECTED] The following snippet: $bunch=10; $_SESSION['mail'] = (int)$_SESSION['mail'] + $bunch; only works with the (int) in front of $_session. Otherwise get "unsupported operand types" error. This is mysterious, Session control in PHP should preserve type. Typical Session file was as follows: mail|i:-1;Mail_title|s:4:"test";Mail_body|s:4:"test"; you see mail was of type i. -- Edit this bug report at http://bugs.php.net/?id=21953&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: Hello all, * PHP Version 4.2.3 * Apache 1.3.27 * Linux * config: ./configure' '--with-apxs' '--with-oci8=/usr/local/oracle/m01/app/oracle/product/8.1.7/' '--with-openssl' '--with-curl' '--with-mysql' I'm having this problem every day, and can reproduce at will. Extremely frustrating. For me it only occurs upon (successful) login to my site. Instead of going to the php index, I get a "Page cannot be displayed". I'm using non-cookie sessions managed by an Oracle database. Once I am in, past the login, the error never occurs however. It seems only to be a problem when the session is first initialized via session_start(). After this, I pass the sid via the URL, and its subsequently checked by the target script against the oracle db for authenticity- No problems at all there. Does anybody else see this problem occur only upon doing things such as logging in? Thanks, J. Murray HX Technologies Previous Comments: [2003-01-08 11:45:20] [EMAIL PROTECTED] Further testing shows that on Windows 2000 Server with Identical Configurations as the Windows 2000 Pro (I did diffs to be sure) reveals: Win2000Server 2 Processor- 2 failues in an estimates 300,000 tests. Win2000Server 4 processor - 0 failures in 1000 tests (Just started running this one.) Basically I had everyone in the office run the test against the 2 Processor system at the same time. Only 2 failures in that many requests I can live with. So is it more of an issue on less capable systems? [2003-01-08 01:52:58] [EMAIL PROTECTED] interesting. However, I switched my session manager to a dbase function and it still died. How would file locking effect that? I'm interested in the fact though that you can actually witness the bug first hand. I only saw that it was happening. However, I could never get the thing to happen to me. Also, since I have gone to my own session code without using php's built in sessions, I don't have problems at all anymore. Josh [2003-01-08 01:19:06] [EMAIL PROTECTED] My script will fail in as short as 1 request or over 1000 requests. I did set session.gc_probability = 0 but still fails. -Ryan [2003-01-08 01:13:53] [EMAIL PROTECTED] I CAN REPRODUCE THIS BUG!!! Sort ofÂ… I too had my software working perfectly for over a year under PHP 4.0.6 / Apache 1.3.24 on Win2000 Pro (development) Win2000 Server (production). After upgrading to PHP 4.2.3 / Apache 1.3.27 I've been pulling my hair out with this session disappearing problem. I tried just about everything I could find in the bug lists mentioned in this bug to no avail, short of trying latest CVS. I'm short on time and resources and from what I read; they haven't fixed the problem yet. As far as it being a serialization problem I don't think so. None of my session variables are more complex than a string. So I wrote a simple test and I know it's not IE specific. I could recreate the problem with IE 6, Opera 6.05, Netscape 7.0, and Mozilla 1.3 I striped the test to be as simple as 1 integer as a session variable and it would still die. I removed the counting aspect to verify it wasn't a write problem, just reading session data would kill it as well. The error seems to occur if requests are made to the session variable from different files close enough together in time to cause one to "lock" the session file while the next request tries to access it. Resulting in this error: Warning: open(c:\tmp\sess_c6bdd642a5d88639e785ec13b0d2f126, O_RDWR) failed: Permission denied (13) in c:\apache\htdocs\testing\session2.php on line 10 Obviously it DOES have permission or else my scripts would fail all the time. This does fail on all Windows servers I tested with PHP 4.2.3. I did try it on a Slackware 8.1 with PHP 4.2.1 / Apache 1.3.24 and it did NOT fail. I hope this helps track down the elusive bug so I don't have to downgrade back to 4.0.6 but I'm left with few options. I will try a CVS if you think it might fix it but I've already spent more time than I have on this. And from what I read, they don't fix it. If you need more info just ask. I'll try to do what I can. My test consists of 4 files. Obviously the comments are not part of the files. //file: session0.php // Just used to clean things up when they get ugly. //--- Session Test Load Values //--
#21948 [Fbk->Opn]: Reproducible segfaults when running IMP over SSL
ID: 21948
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: RedHat Linux 7.3
PHP Version: 4.3.0
New Comment:
Ok here's a more specific dump. First the configuration:
--enable-debug=yes
--disable-rpath
--with-openssl
--with-regex=system
--with-layout=GNU
--with-kerberos=/usr/kerberos
--enable-debugger
--enable-sockets
--with-imap
--with-imap-ssl
--with-mysql=/usr
--enable-wddx
--with-gettext
This seems to be as small as I could get it and still compile PHP and
run IMP (my c-client is built with kerberos so I had to enable that,
for example.)
Here is the resulting crash dump:
#0 0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1 0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2 0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3 0x4202b33f in putenv () from /lib/i686/libc.so.6
#4 0x404ab54c in zif_putenv (ht=1, return_value=0x88b4bb4,
this_ptr=0x0, return_value_used=0)
at
/home/jmt/rpm/BUILD/php-4.3.0/ext/standard/basic_functions.c:1353
#5 0x405645d3 in execute (op_array=0x8b5c55c) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1596
#6 0x405647af in execute (op_array=0x8ae43e4) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#7 0x405647af in execute (op_array=0x8bf06c4) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#8 0x405647af in execute (op_array=0x8c7bc34) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#9 0x40569dee in execute (op_array=0x8836b34) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:2162
#10 0x4054f48c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/jmt/rpm/BUILD/php-4.3.0/Zend/zend.c:864
#11 0x40522d36 in php_execute_script (primary_file=0xb140) at
/home/jmt/rpm/BUILD/php-4.3.0/main/main.c:1573
#12 0x4056c75a in apache_php_module_main (r=0x87d0a00,
display_source_mode=0)
at /home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/sapi_apache.c:55
#13 0x4056d36b in send_php (r=0x87d0a00, display_source_mode=0,
filename=0x0)
at /home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/mod_php4.c:556
#14 0x4056d3c3 in send_parsed_php (r=0x87d0a00) at
/home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/mod_php4.c:571
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Hope this helps.
Previous Comments:
[2003-01-30 13:43:31] [EMAIL PROTECTED]
And cut down the amount of the configure options, to bare minimum to
get IMP work. And ditch the 'shared' options too.
[2003-01-29 15:06:24] [EMAIL PROTECTED]
I spoke too soon, the crash is still there. Am attempting to get a core
file now to generate another backtrace to see if its the same problem
or not.
bug 21804 seems like it may be related to this issue as well.
[2003-01-29 14:05:43] [EMAIL PROTECTED]
It is compiled with --enable-debug (see config list above), which is
why I made the note that the backtrace was somewhat baffling. I ran gdb
across libphp4.so just to confirm that it does indeed load debugging
symbols so they ARE there.
FYI I removed the SetEnvIf directive and the crashes have gone away it
seems.
[2003-01-29 13:56:17] [EMAIL PROTECTED]
Please compile PHP with --enable-debug, that will result in more
detailed backtraces.
[2003-01-29 12:32:18] [EMAIL PROTECTED]
I am getting a reproducible crash (segfaults) on my system using Apache
1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with
the following options:
--enable-force-cgi-redirect
--enable-debug
--enable-pic
--disable-rpath
--enable-inline-optimization
--with-bz2
--with-db3
--with-curl
--with-dom=%{_prefix}
--with-exec-dir=%{_bindir}
--with-freetype-dir=%{_prefix}
--with-png-dir=%{_prefix}
--with-gd
--enable-gd-native-ttf
--with-ttf
--with-gdbm
--with-gettext
--with-ncurses
--with-gmp
#21982 [Opn->Csd]: imap_fetchstructure crashes php on apache
ID: 21982 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: IMAP related Operating System: linux PHP Version: 4.2.2 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2003-01-31 08:15:42] [EMAIL PROTECTED] imap_fetchstructure crashes PHP on Apache when try to read mailbox witch such message header: == Return-Path: <[EMAIL PROTECTED]> X-Sieve: cmu-sieve 2.0 Received: from vilnius.balt.net (vilnius.balt.net [195.14.170.14]) by calypso.bi.lt (Postfix) with SMTP id 311311B32A5 for <[EMAIL PROTECTED]>; Tue, 14 Jan 2003 15:56:37 +0200 (GMT-2) Received: (qmail 31283 invoked from network); 14 Jan 2003 13:56:28 - Received: from ip-195-14-171-1.bnk.lt (HELO DARIUS) (195.14.171.1) by vilnius.balt.net with SMTP; 14 Jan 2003 13:56:28 - Date: Tue, 14 Jan 2003 16:00:52 +0100 From: InfoUltra <[EMAIL PROTECTED]> X-Mailer: The Bat! (v1.41) UNREG / CD5BF9353B3B7091 Reply-To: InfoUltra <[EMAIL PROTECTED]> X-Priority: 3 (Normal) Message-ID: <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], vandad"@socmin.lt>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[E
#21983 [Opn->Fbk]: Php SegFault
ID: 21983
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: linux
PHP Version: 4.3.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Unable to replicate using the latest CVS.
Previous Comments:
[2003-01-31 09:16:50] [EMAIL PROTECTED]
a much simple script to reproduce the crash , with a backtrace:
dom=& $dom;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
return $this->e_resolver;
}
}
$dom=domxml_new_doc('1.0');
$resolver=new resolver($dom,
$HTTP_GET_VARS['nameserver'],$HTTP_GET_VARS['domain'],"");
$resolver=$resolver->write_xml();
$servers=array($int_eth0, $int_eth1);
$network=$dom->create_element('network');
$network->append_child($resolver);
?>
[2003-01-31 08:44:47] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2003-01-31 08:37:20] [EMAIL PROTECTED]
$php file.php
Segmentation fault
$
---file.php---
dom=& $dom;
$this->basename=$basename;
$this->network=$network;
$this->proxy=$proxy;
}
function &write_xml () {
$this->e_zactivbox=$this->dom->create_element('zactivbox');
$this->e_zactivbox->set_attribute('basename', $this->basename);
$this->e_zactivbox->append_child($network);
$this->e_zactivbox->append_child($proxy);
return $this->e_zactivbox;
}
}
class network {
var $servers; //array of server
var $route;
var $resolver;
var $dom;
var $e_network;
function network (&$dom, $servers, $route, $resolver) {
$this->dom=& $dom;
$this->servers=$servers;
$this->route=$route;
$this->resolver=$resolver;
}
function &write_xml() {
$this->e_network=$this->dom->create_element('network');
foreach($this->servers as $key => $server)
{
$this->e_network->append_child($server);
}
$this->e_network->append_child($this->route);
$this->e_network->append_child($this->resolver);
return $this->e_network;
}
}
class resolver {
var $domain;
var $search;
var $nameserver;
var $dom;
var $e_resolver;
function resolver (&$dom, $nameserver, $domain='', $search='') {
$this->dom=& $dom;
$this->domain=$domain;
$this->search=$search;
$this->nameserver=$nameserver;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
$e_domain=$this->dom->create_element('domain');
$t_domain=$this->dom->create_text_node($this->domain);
$e_domain->append_child($t_domain);
$this->e_resolver->append_child($e_domain);
$e_search=$this->dom->create_element('search');
$t_search=$this->dom->create_text_node($this->search);
$e_search->append_child($t_search);
$this->e_resolver->append_child($e_search);
$t_nameserver=$this->dom->create_text_node($this->nameserver);
$e_nameserver=$this->dom->create_element('nameserver');
$e_nameserver->append_child($t_nameserver);
$this->e_resolver->append_child($e_nameserver);
return $this->e_resolver;
}
}
class route {
var $destination;
var $iface;
var $ip;
var $dom;
var $e_route;
function route (&$dom, $destination, $ip, $iface) {
$this->dom=& $dom;
$this->destination=$destination;
$this->ip=$ip;
$this->iface=$iface;
}
function &write_xml() {
$this->e_rou
#16456 [Opn->Csd]: "resume" of ftp downloads
ID: 16456 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The 'resumepos' parameter was added to ftp_get() as of PHP 4.3.0 Previous Comments: [2002-04-05 12:58:42] [EMAIL PROTECTED] It would be handy to be able to use the ftp REST command to resume a long download. If I'm seeing this correctly, this would require an option to save partial downloads (or does it do this already?). I don't know whether it would be better to add an optional "start from byteX" field to the ftp_get() functions or to have a separate "ftp_getrest()" function, or what, but thought I'd ask... -- Edit this bug report at http://bugs.php.net/?id=16456&edit=1
#21989 [NEW]: openssl_csr_new causes apache+modphp to segfault
From: [EMAIL PROTECTED] Operating system: Linux x86 (2.4.x, glibc 2.3) PHP version: 4.3.0 PHP Bug Type: OpenSSL related Bug description: openssl_csr_new causes apache+modphp to segfault When php 4.3.0 is compiled as loaded as an apache module (apache 1.3.27 from Debian Linux) accessing the function openssl_csr_new causes apache to segfault. Building php as a CGI this apparently does not happen (but I've not investigated this all that closely). Attaching to the apache process (where modphp has been build with symbols) shows the actual segfault occurs inside php_openssl_make_REQ (no stack trace available as I guess something get's clobbered and messes this up). Placing a breakpoint at php_openssl_make_REQ I see it is entered with a stack of: Breakpoint 2, php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1143 1143STACK_OF(CONF_VALUE) * dn_sk, *attr_sk = NULL; (gdb) bt #0 php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1143 #1 0x403a8429 in zif_openssl_csr_new (ht=2, return_value=0x81163ec, this_ptr=0x0, return_value_used=1) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1583 #2 0x404adf62 in execute (op_array=0x811333c) at /home/cw/wk/zaphod/php4/php4-4.3.0/Zend/zend_execute.c:1596 #3 0x4049af24 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cw/wk/zaphod/php4/php4-4.3.0/Zend/zend.c:864 #4 0x4045fd53 in php_execute_script (primary_file=0xb764) at /home/cw/wk/zaphod/php4/php4-4.3.0/main/main.c:1573 #5 0x404b3470 in apache_php_module_main (r=0x8109564, display_source_mode=0) at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/sapi_apache.c:55 #6 0x404b4410 in send_php (r=0x8109564, display_source_mode=0, filename=0x810b0dc "/var/www/other.php") at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/mod_php4.c:556 #7 0x404b448f in send_parsed_php (r=0x8109564) at /home/cw/wk/zaphod/php4/php4-4.3.0/sapi/apache/mod_php4.c:571 #8 0x08053b34 in ap_invoke_handler () #9 0x0806368c in ap_some_auth_required () #10 0x080636e8 in ap_process_request () #11 0x0805ce2b in ap_child_terminate () #12 0x0805cfbc in ap_child_terminate () #13 0x0805d0d9 in ap_child_terminate () #14 0x0805d5b5 in ap_child_terminate () #15 0x0805dcbd in main () #16 0x400e59f1 in __libc_start_main () from /lib/libc.so.6 and then dies at php4-4.3.0/ext/openssl/openssl.c line 1185 (the call to X509_NAME_add_entry_by_NID): Breakpoint 4, php_openssl_make_REQ (req=0xbfffcf24, csr=0x8116c70, dn=0x8117e1c, attribs=0x0) at /home/cw/wk/zaphod/php4/php4-4.3.0/ext/openssl/openssl.c:1185 1185if (!X509_NAME_add_entry_by_NID(subj, nid, MBSTRING_ASC, (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x402c6f8b in sk_value () from /usr/lib/i686/cmov/libcrypto.so.0.9.6 (gdb) I don't know enough about this call, php or indeed anything to really know what variables to poke and look at further. -- Edit bug report at http://bugs.php.net/?id=21989&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21989&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21989&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21989&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21989&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21989&r=support Expected behavior: http://bugs.php.net/fix.php?id=21989&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21989&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21989&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21989&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21989&r=gnused
#21685 [Fbk->NoF]: xmlrpc_decode() causes segfault
ID: 21685 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: XMLRPC-EPI related Operating System: Redhat Linux 7.3 PHP Version: 4CVS-2003-01-16 (stable) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-17 09:13:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot replicate with latest snapshot. [2003-01-17 06:02:42] [EMAIL PROTECTED] Backtrace: #0 0x081caea6 in zif_xmlrpc_decode (ht=1, return_value=0x84f0774, this_ptr=0x0, return_value_used=1) at /usr/src/cvs/php4/ext/xmlrpc/xmlrpc-epi-php.c:776 #1 0x0822e22b in execute (op_array=0x84f1314) at /usr/src/cvs/php4/Zend/zend_execute.c:1596 #2 0x0821be34 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/cvs/php4/Zend/zend.c:925 #3 0x081e3dd7 in php_execute_script (primary_file=0xbab0) at /usr/src/cvs/php4/main/main.c:1691 #4 0x08235dde in main (argc=2, argv=0xbb54) at /usr/src/cvs/php4/sapi/cli/php_cli.c:753 #5 0x401524ce in __libc_start_main () from /lib/libc.so.6 [2003-01-16 04:53:51] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2003-01-16 04:52:46] [EMAIL PROTECTED] When using the xmlrpc_decode() function, the Apache2 (latest cvs) reports a segfault in the error-log. I've tested it with various xmlrpc-responses like: South Dakota "); ?> Here is my ./configure : './configure' '--prefix=/usr' '--with-config-file-path=/etc/server' '--with-apxs2=/usr/bin/apxs' '--with-pear=/home/httpd/include' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--enable-dio' '--enable-dbase' '--enable-dx' '--enable-exif' '--enable-ftp' '--enable-mime_magic=/etc/server/mime' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--enable-shmop' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-wddx' '--enable-yp' '--with-xmlrpc' '--with-mnogosearch=/usr' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--with-imap' '--with-ldap' '--enable-cli=yes' '--with-gettext' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--enable-dbase' '--with-pspell' '--with-pdflib' '--with-iconv' '--with-zlib-dir' '--with-jpeg-dir' '--with-expat-dir=/usr' '--with-readline' '--with-mcrypt=/usr' '--with-unixodbc' '--enable-dba' '--with-db4' '--with-gdbm' '--with-gmp' '--with-curlwrappers' -- Edit this bug report at http://bugs.php.net/?id=21685&edit=1
#21676 [Fbk->NoF]: GetImageSize nolonger works
ID: 21676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: GetImageSize related Operating System: RAQ4-Latest Patches/Apache 1.3.2 PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-16 13:47:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I cannot replicate the described bug using latest snapshot. If you still experience the problem try using the bundled GD library. [2003-01-16 13:34:50] [EMAIL PROTECTED] This image returns null information on GetImageSize: http://www.blackpeeps.com/IV/ecnirp/img3d6ea40af403a.jpg This image does return correct Width and Height info: http://www.blackpeeps.com/IV/ecnirp/img3e124d90c8123.jpg I have even tried downloading the first and uploading back to server to make sure there is not a Binary file transfer issue. No luck. Here is a file that my Thumbnail script is not creating a thumbnail for. Well, actually, it creates a Blacked out thumbnail. The script uses ( GetImgageSize , imagecreatetruecolor, and ImageCreateFromJPEG ) http://www.blackpeeps.com/IV/ecnirp/img3cae54c4a3771.jpg [2003-01-16 13:32:53] [EMAIL PROTECTED] This image returns null information on GetImageSize: http://www.blackpeeps.com/IV/ecnirp/img3d6ea40af403a.jpg This image does return correct Width and Height info: http://www.blackpeeps.com/IV/ecnirp/img3e124d90c8123.jpg";; I have even tried downloading the first and uploading back to server to make sure there is not a Binary file transfer issue. No luck. Here is a file that my Thumbnail script is not creating a thumbnail for. Well, actually, it creates a Blacked out thumbnail. The script uses ( GetImgageSize , imagecreatetruecolor, and ImageCreateFromJPEG ) http://www.blackpeeps.com/IV/ecnirp/img3cae54c4a3771.jpg [2003-01-16 12:51:12] [EMAIL PROTECTED] GetImageSize is not related to GD in anyway. Please provide a sample image, which could be used to duplicate the problem you describe. [2003-01-15 23:20:36] [EMAIL PROTECTED] Recently upgraded to PHP 4.3.0 with GD-2.0.1 Scripts worked fine before upgrade. After 4.3.0 upgrade, Sometimes GetImageSize works (returns probper width and height variables) and sometimes it does not (my resize functions are defaulting to 1x2 pixels) At first I thought the problem was isolated to jpgs created with prior version PHP 4.1.2 and GD-2.0.0 and imagecreatefromjpeg function. Then I noticed that there are photos were an image tag (imagecreatefromjpeg) was not used. So the problem is only occuring with certain files.) -- Edit this bug report at http://bugs.php.net/?id=21676&edit=1
#21664 [Fbk->NoF]: Apache 1.3.x on Oracle9iAS
ID: 21664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Linux Redhat 7.3 PHP Version: 4.2.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-15 14:23:26] [EMAIL PROTECTED] Please try with PHP 4.3.0. [2003-01-15 10:52:10] [EMAIL PROTECTED] i try compile PHP and i want generate libphp4.o and always output error My configurate line it's: ./configure CPPFLAGS=-I$/u01/app/oracle/product/ora9ias/Apache/Apache/include --with-apxs=/usr/sbin/apxs -enable-shared -with-oci8=/u02/app/oracle/product/8.1.7 --enable-sigchild --with-mysql=/usr --enable-track-vars -enable-module=so But i have this problem: /bin/sh /usr/local/php-4.2.3/libtool --silent --mode=link gcc -I. -I/usr/local/php-4.2.3/ -I/usr/local/php-4.2.3/main -I/usr/local/php-4.2.3 -I/usr/include/apache -I/usr/local/php-4.2.3/Zend -I/usr/include/mysql -I/u02/app/oracle/product/8.1.7/rdbms/public -I/u02/app/oracle/product/8.1.7/rdbms/demo -I/usr/local/php-4.2.3/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/usr/local/php-4.2.3/TSRM -g -O2 -prefer-pic -o libphp4.la -rpath /usr/local/php-4.2.3/libs -avoid-version -L/usr/lib/mysql -L/u02/app/oracle/product/8.1.7/lib -R /usr/lib/mysql -R /u02/app/oracle/product/8.1.7/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la regex/libregex.la /usr/local/php-4.2.3/ext/ctype/libctype.la /usr/local/php-4.2.3/ext/mysql/libmysql.la /usr/local/php-4.2.3/ext/oci8/liboci8.la /usr/local/php-4.2.3/ext/pcre/libpcre.la /usr/local/php-4.2.3/ext/posix/libposix.la /usr/local/php-4.2.3/ext/session/libsession.la /usr/local/php-4.2.3/ext/standard/libstandard.la /usr/local/php-4.2.3/ext/xml/libxml.la TSRM/libtsrm.la -lpam -lmysqlclient -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -ldl -lm -lclntsh -ldl *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. /usr/bin/ld: cannot open output file .libs/: Is a directory collect2: ld returned 1 exit status make[1]: *** [libphp4.la] Error 1 make[1]: Leaving directory `/usr/local/php-4.2.3' make: *** [all-recursive] Error 1 Someone can helpme -- Edit this bug report at http://bugs.php.net/?id=21664&edit=1
#20166 [Fbk->NoF]: Unicode (Slovenian) characters are not displayed correctly
ID: 20166
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: *Languages/Translation
Operating System: Win2k
PHP Version: 4.2.2
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-01-18 15:13:08] [EMAIL PROTECTED]
Doesn't your problem look like the one reported in the following bug
report?
http://bugs.php.net/19474
[2002-11-08 00:06:19] [EMAIL PROTECTED]
A simple output of the three versions:
MSSQL accessed trough ADO COM object:
title: Novela zakona o državljanstvu ne rešuje nièesar
PHP Mssql extension:
title: Novela zakona o dr§avljanstvu ne reçuje niŸesar
MYSQL (entered trough command line)
String: Ÿç§¬æ¦ string
MYSQL (entered trough php form)
String: 蚞 string
[2002-11-05 00:29:14] [EMAIL PROTECTED]
Hi!
To define more clearly:
I have a Microsoft SQL database. In that database, there are many
articles, with pictures, etc. I tried to access those articles using
php, and wanted to display them. All is fine, but, instead of slovene
characters 蚞 (which you probably don't see anyway) I get garbles
(unrecognized characters). I was using mssql_* functions to retrieve
the data. Then, I created a simple table in mysql, inserted a row
manually (from the console) and the same thing happens. BUT, if I
insert the items trough PHP the first time, than the characters are
retrieved correctly. So I suspect there must be something with
encoding, perhaps. To make things even more funny, when I used ADO COM
object to access the MS SQL server, the strings retrieved are fine.
I apologize if I posted this under the wrong category, but I could not
decide whether it is a db problem or not. Feel free to move this item
to another category, if you wish.
System details: SQL Server: Win2k, Slovenian locale
PHP system: Win2k, Apache 1.3.26 (Win32), PHP 4.2.2, mysql 3.23.52,
Slovenian locale
[2002-10-30 07:05:53] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2002-10-30 02:45:23] [EMAIL PROTECTED]
The problem is with Microsoft SQL Server 2000 and with MySQL version
Ver 11.18 Distrib 3.23.52, for Win95/Win98 (i32).
I have a database with slovenian characters in the fields and I am not
able to display them properly with php extension modules. I can display
them propery using COM ADO objects. I've included a simple script, that
shows what I am trying to do. The ADO portion of the script produces
the desired result. The characters are entered using windows-1250
codepage.
The script:
Open("PROVIDER=MSDASQL;DRIVER={SQL SERVER};
Server=SRRDEV2;Database=portal;UID=sa;PWD=srrdev2;");
// SQL statement to build recordset.
$rs = $conn->Execute("SELECT * FROM TblInfo_News where IID = 3034326");
while (!$rs->EOF) {
$fv = $rs->Fields("title");
echo "title: ".$fv->value."\n";
$rs->MoveNext();
}
$rs->Close();
?>
PHP Mssql extension:
";
}
} else {
echo "No results! ";
}
mssql_free_result($result);
} else {
echo "Could not get the result!";
}
mssql_close($link);
} else {
echo "Could not select db!";
}
} else {
echo "Could not connect!";
}
// mysql
echo "MYSQL";
$link = mysql_connect("valencicm.mobitel.si", "root", "root")
or die("Could not connect");
mysql_select_db("test");
$query = "SELECT * FROM tbl1";
$result = mysql_query($query);
if($result) {
$row = mysql_fetch_array($result);
if($row) {
echo "String: " . $row['fld1'];
}
mysql_free_result($result);
}
mysql_close($link);
?>
#21686 [Fbk->NoF]: ImageColorExact
ID: 21686 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: GD related Operating System: LINUX PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-16 12:53:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. cannot replicate the bug. [2003-01-16 06:47:03] [EMAIL PROTECTED] ImageColorExact() returns the biggest int value insted of -1 if the color specified is not in the palette. -- Edit this bug report at http://bugs.php.net/?id=21686&edit=1
#21696 [Fbk->NoF]: Checkbox is strange in POST event
ID: 21696
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: *General Issues
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-01-17 20:17:34] [EMAIL PROTECTED]
If you're really using Apache2, consider moving to Apache 1.3.27 which
actually works.
[2003-01-17 09:10:07] [EMAIL PROTECTED]
are you sure that your error_reporting settings are really the same on
both boxes? (pleas check in phpinfo() output)
the message you see is only produced if E_NOTICE reporting is enabled
...
[2003-01-17 05:18:53] [EMAIL PROTECTED]
First, thanks for your attention.
a) I'm running the same script in other machine, and it's passing NULL
("") string. I suppose the other machine, with the same configuration,
should have the same behavior.
b) Do I have to create the variable? Again, it's running in other
machine with no problems. And all of my variables are created in the
moment I need them. Did I miss something about PHP?
c) I'll test.
d) You are right, sorry, I mean register_globals is off
e) I'll read.
[2003-01-16 16:00:16] [EMAIL PROTECTED]
Four things:
a) Only checked checkboxes pass values.
b) Why do you expect $a to exist at all? I see no code that creates
$a.
c) Have your test (form2.php) simply be:
print_r($HTTP_POST_VARS);
d) I believe you mean register_globals is off, there is no such thing
as global_variables.
e) http://www.php.net/variables.external
[2003-01-16 15:43:31] [EMAIL PROTECTED]
ARGH! actually, ignore that comment... I'm talking bs right now :|
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/21696
--
Edit this bug report at http://bugs.php.net/?id=21696&edit=1
#21710 [Fbk->NoF]: Make install fail with memory fault
ID: 21710 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: OSF1 V5.1 alpha PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-17 09:38:29] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Could you please supply a backtrace. [2003-01-17 07:02:37] [EMAIL PROTECTED] I am trying to install the php under a True64 cluster. We have an apache web server (1.3.26) running on it an a mysql server. I try to install last version of php-4.3.0: ./configure --with-mysql --with-apxs=/path_to_apxs --prefix=install_path --with-config-file-path=path_file make make install the last command fails with the following message: >> Installing shared extensions: /ebi/www/php/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /ebi/www/php/lib/php/ sh: 1943471 Memory fault - core dumped *** Exit 139 Stop. *** Exit 1 << I try to download the last snapshot from: http://snaps.php.net/ download: php4-STABLE-200301171230.tar.gz but it gives me the same message. Is it a bug? or could it be fixed? Thanks for your help, Xavi -- Edit this bug report at http://bugs.php.net/?id=21710&edit=1
#21719 [Fbk->NoF]: 4.3.0 Won't compile.
ID: 21719
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Compile Failure
Operating System: Redhat 7.0 (Kernel 2.4.5)
PHP Version: 4.3.0
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-01-17 19:57:34] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2003-01-17 18:48:56] [EMAIL PROTECTED]
4.3.0 Won't compile.
getting this error:
checking whether fp_except is defined... no
checking whether dlsym() requires a leading underscore in symbol
names... ./configure: line 76778: syntax error near unexpected token
`_LT_AC_TRY_DLOPEN_SELF('
./configure: line 76778: `_LT_AC_TRY_DLOPEN_SELF('
--
Edit this bug report at http://bugs.php.net/?id=21719&edit=1
#21091 [Fbk->NoF]: undefined reference to `ssl_onceonlyinit'
ID: 21091 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IMAP related Operating System: Debian Woody PHP Version: 4.3.0RC3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-18 01:07:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2002-12-18 23:27:15] [EMAIL PROTECTED] Configuring PHP with: ./configure --prefix=/usr --sysconfdir=/etc --with-apxs2 --with-config-file-path=/etc --with-pear=/usr/share/pear --with-openssl --with-zlib --with-bz2 --with-dom --with-dom-xslt --enable-exif --enable-ftp --with-gd --with-gettext --with-iconv --with-imap --with-imap-ssl --with-mcrypt --with-mysql --with-pcntl --with-pgsql --with-pspell --enable-trans-sid The compilation fails when it tries to compile the IMAP support, complaining about: ext/imap/php_imap.lo: In function `zm_startup_imap': /home/users/jon/src/php4/ext/imap/php_imap.c:424: undefined reference to `ssl_onceonlyinit' collect2: ld returned 1 exit status I can get it to compile by going into the file and commenting out that line, but I don't know what effect that's going to have on stability. [2002-12-18 23:17:12] [EMAIL PROTECTED] Configuring PHP with: ./configure --prefix=/usr --sysconfdir=/etc --with-apxs2 --with-config-file-path=/etc --with-pear=/usr/share/pear --with-openssl --with-zlib --with-bz2 --with-dom --with-dom-xslt --enable-exif --enable-ftp --with-gd --with-gettext --with-iconv --with-imap --with-imap-ssl --with-mcrypt --with-mysql --with-pcntl --with-pgsql --with-pspell --enable-trans-sid The compilation fails when it tries to compile the IMAP support, complaining about: ext/imap/php_imap.lo: In function `zm_startup_imap': /home/users/jon/src/php4/ext/imap/php_imap.c:424: undefined reference to `ssl_onceonlyinit' collect2: ld returned 1 exit status I have installed the version of c-client using apt-get, so I assume I'm using a fairly recent version of c-client. -- Edit this bug report at http://bugs.php.net/?id=21091&edit=1
#21556 [Fbk->Csd]: fgetcsv hangs if the csv file contains a "
ID: 21556
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type:Filesystem function related
PHP Version: 4.3.0
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-01-09 17:10:41] [EMAIL PROTECTED]
I've just commited a patch to the CVS that may resolve the problem,
please wait a few hours and then grab a snapshot from
http://snaps.php.net/.
[2003-01-09 16:32:39] [EMAIL PROTECTED]
Yeah,
Just copy this text to a file and then save it as test.csv
just a bunch of data, jere, fadjsfd, aksjfllsd, adfjsdkl
fajsdlfls, afdlsfkjfdsal, adjfsljfas, adfjsldkfjs, dkslafj
fjadskjf, aksdjfls, afksfdjl""", jlkjl, jlkjkl, jlkjl, jlak
fajlsd, jfadlsl, ajfldsja, akfjsdl, ajsdflj, ajdskfks
as you will see it hangs on the third line
[2003-01-09 16:24:37] [EMAIL PROTECTED]
Could you please provide a sample csv file that could be used to
replicate the problem.
[2003-01-09 16:01:36] [EMAIL PROTECTED]
Usings the basic fgetcsv example,
$num fields in line $row: \n";
$row++;
for ($c=0; $c < $num; $c++) {
print $data[$c] . "\n";
}
}
fclose ($fp);
?>
If the CSV contains a double quote, fgetcsv hangs on that line and
memory utilization spikes. I have reproduced this.
--
Edit this bug report at http://bugs.php.net/?id=21556&edit=1
#21576 [Fbk->NoF]: PHP crashes on mail() using IIS's mail
ID: 21576
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Mail related
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-01-15 13:16:36] [EMAIL PROTECTED]
Oops, wrong status, should be Feedback.
[2003-01-15 13:15:23] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-11 01:46:25] [EMAIL PROTECTED]
When I use the mail() function, PHP crashes with the following error:
"PHP has encountered an Access Violation at 01AD7BD4"
For my mail server, I'm using the IIS mail server ("default SMTP
virtual server") on localhost.
I'm using IIS 5 (Dont know where to get an exact ver number) for both
php and email and windows 2000 (version 5.00.2195 [service pack 2])
The mail does get sent successfully even with the error.
the same code works fine on my redhat server using sendmail (same php
version)
--
Edit this bug report at http://bugs.php.net/?id=21576&edit=1
#21540 [Fbk->NoF]: include_path problem
ID: 21540 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-15 03:08:25] [EMAIL PROTECTED] But your include_path definition is different than the one mentioned in the error message..are you sure your php.ini is used by PHP ? [2003-01-12 06:13:01] [EMAIL PROTECTED] Yes, I have the following line in php.ini include_path= .:./:/usr/local/src/php-4.1.1/php-4.1.1/pear [2003-01-10 16:37:59] [EMAIL PROTECTED] Do you have include_path specified in your php.ini? [2003-01-10 01:53:50] [EMAIL PROTECTED] I'm running Apache 1.3.27. I tried include_path both in httpd.conf and .htaccess. Problem existed in both cases. [2003-01-09 19:42:16] [EMAIL PROTECTED] Which Apache are you using and where are you specifying the include_path, httpd.conf (virtual host) or .htaccess? 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/21540 -- Edit this bug report at http://bugs.php.net/?id=21540&edit=1
#21464 [Fbk->NoF]: imap_get_quota broken in php4.3.0?
ID: 21464 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IMAP related Operating System: UnitedLinux 1.0 PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-17 09:13:47] [EMAIL PROTECTED] Well the work around is a nice fix, and thats exactly how I confirmed that the function was working when I wrote it. Tested on cyrus as well (it still does work for my test cases too). But that doesn't really help fix the bug (if there is one) in PHP. Judging from the second paragraph though I'm going to assume this is a local configuration issue. I'll leave this set to feedback for a while unless you find some new information... it will be closed in about 30 days. [2003-01-17 04:33:36] [EMAIL PROTECTED] me again.. solved the problem temporarily by connecting to cyrus imapd using fsockopen and uning imap-commands (around 6 lines code) i have the code on my computer at home, does someone like it? the problem may be outside php on a different server running SuSE 7.1/apache1.3.26 IMP run´s fine with the original imap_get_quota Syntax and php 4.3.0/imap-2000a (without ssl) [2003-01-17 00:53:52] [EMAIL PROTECTED] have you spoken to the developers of IMP? The parameters of the function haven't changed, only the output has to correct for a bug that returned the incorrect results for a quota (pretty regularly too). There is some backward compatibility code added in to ease the transition, but since I'm not that familiar with IMP I can't comment on how it is using the code. [2003-01-16 16:47:29] [EMAIL PROTECTED] I run into the same problem. I just compiled php 4.3.0 and I installed IMP 3.1. When IMP executes the command imap_get_quota or imap_get_quotaroot, the PHP processor barks: Fatal error: Call to undefined function: imap_get_quota() in /usr/local/www/ideastar_mail/horde/imp/config/conf.php on line 391 I know IMAP is working, as the rest of IMP is working fine and the other imap commands work fine. [2003-01-06 10:48:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Marking as bogus, because the functionality of imap_get_quota was changed a bit to correct for a bug (which basically returned the wrong values). You might want to try a newer IMP, or give a bit more information as to what is broken in the function. 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/21464 -- Edit this bug report at http://bugs.php.net/?id=21464&edit=1
#21390 [NoF->Bgs]: php.exe does not work - needs Kernel32.dll::CancelIo
ID: 21390 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: Reproducible crash Operating System: Windows 95 PHP Version: 4.3.0 New Comment: Oops..we don't support win95 anymore since 4.3.0.. (there's another report about this too..in "Documentation problem" category) Previous Comments: [2003-01-31 13:45:07] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-01-16 03:56:01] [EMAIL PROTECTED] Try: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-16 02:08:25] [EMAIL PROTECTED] I get 'permission denied' when I try to access the Windows snapshot. [2003-01-07 19:43:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2003-01-03 08:12:10] [EMAIL PROTECTED] PHP.exe (45056 bytes) does not work on Win95. It imports CancelIo from Kernel32.dll, but this routine does not exist in Kernel32 on Windows 95! Previous version (4.2.3) works correctly. There is nothing about it in PHP documentation and install.txt, maybe documenation problem? P.S. mod_php under Apache works OK. CLI version works too. There is only non-CLI php.exe 4.3.0 problem. -- Edit this bug report at http://bugs.php.net/?id=21390&edit=1
#21390 [Fbk->NoF]: php.exe does not work - needs Kernel32.dll::CancelIo
ID: 21390 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 95 PHP Version: 4.3.0 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-16 03:56:01] [EMAIL PROTECTED] Try: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-16 02:08:25] [EMAIL PROTECTED] I get 'permission denied' when I try to access the Windows snapshot. [2003-01-07 19:43:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2003-01-03 08:12:10] [EMAIL PROTECTED] PHP.exe (45056 bytes) does not work on Win95. It imports CancelIo from Kernel32.dll, but this routine does not exist in Kernel32 on Windows 95! Previous version (4.2.3) works correctly. There is nothing about it in PHP documentation and install.txt, maybe documenation problem? P.S. mod_php under Apache works OK. CLI version works too. There is only non-CLI php.exe 4.3.0 problem. -- Edit this bug report at http://bugs.php.net/?id=21390&edit=1
#21320 [Fbk->NoF]: open_basedir - not working
ID: 21320 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Filesystem function related Operating System: FreeBSD 4.7 PHP Version: 4.2.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-01-17 22:13:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-02 15:13:40] [EMAIL PROTECTED] Yes /www is a symblink to /home/wwwroot [2003-01-02 14:07:58] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Are /www/www.freshbsd.net/ or /home/wwwroot/192.168.0.1/ symlinks? [2003-01-01 13:33:15] [EMAIL PROTECTED] I got this configuration for one of my vhosts in apache 1.3.27: DocumentRoot /www/192.168.0.1 ServerName 192.168.0.1 ErrorLog /var/log/httpd/192.168.0.1-error_log CustomLog /var/log/httpd/192.168.0.1-access_log common php_value open_basedir /home/wwwroot/192.168.0.1/ but when i go in on /home/wwwroot/192.168.0.1/index.php with this script: it will include the page anyway... -- Edit this bug report at http://bugs.php.net/?id=21320&edit=1
#21279 [Fbk->NoF]: odbc_fetch_into returns empty strings for columns with NULL values
ID: 21279
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-01-16 10:56:03] [EMAIL PROTECTED]
It should contain it. You can look into the code though and see for
yourself just to ensure. The fix is in the points that you suggested,
but if it's not working I'm not sure what to tell you other than wait.
[2003-01-06 23:03:13] [EMAIL PROTECTED]
I just tried Win32 build of PHP 4.4.0-dev taken from snaps.php.net
(php4-win32-200301062330.zip) and it is working the same. It looked
like the fix would solve the problem but it works as if the fix was not
applied. Isn't that build supposed to include the fix?
[2003-01-06 12:11:01] [EMAIL PROTECTED]
Try a snapshot dated sometime after this. I believe it does what you
want/desire. If not many complaints happen I'll leave it in...
[2003-01-03 17:09:16] [EMAIL PROTECTED]
What I meant is that every SQL based PHP database API has a function to
fetch rows into an array. When it is not not *_fetch_into is
*_fetch_row.
I do not see any ambiguity in figuring if a result column has a NULL.
As a matter of fact in the current odbc_function of php_odbc.c you
have:
http://cvs.php.net/co.php/php4/ext/odbc/php_odbc.c?r=1.143.2.1
if (result->values[i].vallen == SQL_NULL_DATA) {
Z_STRVAL_P(tmp) = empty_string;
break;
}
Since NULL is always NULL regardless of the data type of a column, all
that needs to be done is to leave undefined (NULL) the respective
column position of the PHP array value returned by the odbc_fetch_into.
[2003-01-03 12:10:44] [EMAIL PROTECTED]
Which other API's are you talking about? Oracle? It's the only other
extension that uses fetch into really.
As for the statement, there is no way for ODBC to really tell either.
The API itself defines this to be rather ambiguous so it becomes
difficult to deal with. At this time the result leaves it to the PHP
user to decide if one is really an emtpy string or NULL rather than the
PHP engine. I tend to think this is a better solution.
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/21279
--
Edit this bug report at http://bugs.php.net/?id=21279&edit=1
#21988 [NEW]: macro replacement with streams
From: [EMAIL PROTECTED] Operating system: sco openserver PHP version: 4.3.0 PHP Bug Type: Compile Warning Bug description: macro replacement with streams php-4.3.0/main/php_streams.h, line 321: warning: no macro replacement within a string literal php-4.3.0/main/php_streams.h, line 322: warning: no macro replacement within a string literal -- Edit bug report at http://bugs.php.net/?id=21988&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21988&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21988&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21988&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21988&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21988&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21988&r=support Expected behavior: http://bugs.php.net/fix.php?id=21988&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21988&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21988&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21988&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21988&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21988&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21988&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21988&r=gnused
#21987 [NEW]: segfault
From: [EMAIL PROTECTED] Operating system: Openbsd 3.2 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: segfault after compiling the new php 4.3.0 using (leaving my old apache alone) ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql --with-openssl --with-gettext --with-xml --with-imap --with-imap-ssl --with-mcrypt --with-zlib then restart time: [root@amanda /home/quel/php-4.3.0] /usr/local/apache/bin/apachectl restart /usr/local/apache/bin/apachectl restart: configuration broken, ignoring restart /usr/local/apache/bin/apachectl restart: (run 'apachectl configtest' for details) [root@amanda /home/quel/php-4.3.0] /usr/local/apache/bin/apachectl configtest Memory fault (core dumped) [root@amanda /home/quel/php-4.3.0] gdb /usr/local/apache/bin/httpd httpd.core #0 0x4019e33a in strcmp () (gdb) bt #0 0x4019e33a in strcmp () #1 0xb380e in obj_name_cmp () bt seems useless and incomplete to me... I once had this problem when getting php 4.2.3 up, however bt showed issues in libc and the problem was related to the --with-kerberos option (which i didn't use this time around) [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=21987&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21987&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21987&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21987&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21987&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21987&r=support Expected behavior: http://bugs.php.net/fix.php?id=21987&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21987&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21987&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21987&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21987&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21987&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21987&r=gnused
#21986 [NEW]: Apache won't start with libphp4.so compiled with OpenSSl 0.9.7
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.6.2 PHP version: 4.3.0 PHP Bug Type: OpenSSL related Bug description: Apache won't start with libphp4.so compiled with OpenSSl 0.9.7 Apache 1.3.27 with modssl 2.8.12: OpenSSL 0.9.7 Returns an error something like: "Undefined symbol OpenSSL_..._noconf" php4.3.0 configured with the following line: './configure' '--with-mysql=/usr/local/mysql' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-track-vars' '--with-pdflib' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--enable-gd-native-ttf' '--with-png-dir=/usr/local/lib' '--with-xpm-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-ttf' '--with-tiff-dir' '--with-zlib' '--enable-ftp' '--enable-cli' '--with-pspell' --with-openssl This bug is similar to bug #21947 it seems that there might be a problem with openSSL 0.9.7 and php 4.3.0 together make test returned 2 FAILS (previously none with openssl 0.9.6e) 1. Fail on error handling 2. Fail on Open SSL create keys (or something like that) Thanks for help and support Peter -- Edit bug report at http://bugs.php.net/?id=21986&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21986&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21986&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21986&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21986&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21986&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21986&r=support Expected behavior: http://bugs.php.net/fix.php?id=21986&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21986&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21986&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21986&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21986&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21986&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21986&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21986&r=gnused
#20274 [Com]: failed to create stream: Too many open files in Unknown on line
ID: 20274
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: iPlanet related
Operating System: Solaris 8
PHP Version: 4CVS-2002-11-06
New Comment:
I have the same problem. I am running iPlanet 6sp3 Enterprise, Solaris
9, PHP 4.3.0. I get this error after
php executes some scripts a few times. I did not have this problem
yesterday with PHP 4.2.3. I don't have any output at this moment. I
just thought i would let you know the problem seems to be widespread.
Previous Comments:
[2003-01-30 02:38:09] [EMAIL PROTECTED]
with solaris 8 iplanet6.0sp5 php4.3.0
I have the same error
before, with solaris 8 iplanet 6.0sp4 php4.2.3, it works fine
but now if i install php4.2.1 or 4.2.3 i have "SIGSEGV 11 segmentation
violation" on my web server.
My configuration is :
gcc 3.2.1
bison 1.875
make 3.80
GNU m4 1.4
autoconf 2.57
automake 1.7.2
binutils 2.11.2
GNU sed 4.0
libtool 1.4
flex 2.5.4a
my configure option is :
./configure --with-nsapi=/path/to/iplanet/web/server'
--with-ldap=/path/to/ldap/ --with-mysql=/path/to/mysql -enable-libgcc
[2003-01-29 11:16:28] [EMAIL PROTECTED]
iPlanet 6sp4 Enterprise, Solaris 8, PHP 4.3.0. I get this error after
php executes a script a few times. This doesn't seem to reproduce
under any certain conditions, typically within a few hits though. I
have 4 other configurations running flawlessly. 2x Solaris 2.6
iPlanet Enterprise 6sp1 and 2x Solaris 8 iPlanet Enterprise 6sp3.
Could this be something with iPlanet's changes with sp4?
Warning:
Unknown(/local/home/cxadmin/content/Sites/Site01/
DocumentRoot/phpinfo.php):
failed to create stream: Too many open files in Unknown on line 0
Warning: Unknown(): Failed opening
'/local/home/cxadmin/content/Sites/Site01/DocumentRoot/
phpinfo.php' for
inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0
MEASURES ALREADY TAKEN:
recompile of the php module ('./configure' '--without-mysql'
'--with-nsapi=/local/Netscape/iplanet/www6.0sp4' '--enable-track-
vars'
'--enable-libgcc' )
Upped the Hard File Descriptor to 7554
explicitly set include path, session.save path, and safe_mode
ENVIRONMENT:
We have this running with out a hitch on two other boxes, under a
similar config, with the exception of there are two instances of
iPlanet running on the box that keeps crashing.
CODE:
// Logic To Decide Which Image To Include
$DESIGN;
if ($SEL == 1) {
$DESIGN="design_1.jpg";
}
else if ($SEL == 2) {
$DESIGN="design_2.jpg";
}
else if ($SEL == 3) {
$DESIGN="design_3.jpg";
}
else if ($SEL == 4) {
$DESIGN="design_4.jpg";
}
else if ($SEL == 5 ) {
$DESIGN="design_5.jpg";
}
else {
$DESIGN="design_6.jpg";
}
//Email Headers
$headers .= "From: ".$FNAME."<".$FEML.">\n";
$headers .= "X-Sender: <".$FEML.">\n";
$headers .= "X-Mailer: <".$FNAME.">\n";
$headers .= "Return-Path: <".$FEML.">\n";
$headers .= "Content-Type: text/html";
// Display Header Content
$Message ="\n";
$Message .="\n";
...Other $Message Code Ommitted to save space
//Mail function (variables are passed from the from on the previous
page)
Globals are set to on
mail($TEML, $TNAME.", You Have An Message From ".$FNAME,
$Message,
$headers);
[2003-01-21 19:14:06] [EMAIL PROTECTED]
Increasing file descriptors only delays the problem.
Our script to monitor the problem reports the following:
Monitoring http://our.site.com
Attempting to contact instance, try # 0
Web server successfully contacted
Too many open files being reported. Likely PHP problem ...
=-=-=-=-=-=-=-=-=-=-= HTML RETURNED =-=-=-=-=-=-=-=-
HTTP/1.1 200 OK
Connection: close
Date: Wed, 22 Jan 2003 00:50:00 GMT
Server: Netscape-Enterprise/6.0
Content-Type: text/html
Client-Date: Wed, 22 Jan 2003 00:50:01 GMT
Client-Peer: 192.10.1.2:80
X-Powered-By: PHP/4.3.0
Warning: Unknown(/site/web/index.php): failed to create stream:
Too many open files in Unknown on
line 0
Warning: Unknown(): Failed opening '/site/web/index.php' for
inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line
0
Shutting down server with script: /web/https-web-server/stop
Restarting server with script: /web/https-web-server/start
done.
Attempting to contact instance, try # 1
Web server successfully contacted
PHP problems resolved by restarting web server
Where can I go from here?
[2002-12-27 01:00:04] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
informati
#21985 [NEW]: mb_send_mail() doesn't encode the message body into MIME base64
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.3.0 PHP Bug Type: mbstring related Bug description: mb_send_mail() doesn't encode the message body into MIME base64 I'm trying to send a UTF-8 encoded e-mail using mb_send_mail() under PHP 4.3.0 with the MBString extension. mb_send_mail() adds the following lines to the e-mail header: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: BASE64 But it doesn't encode the message body into MIME base64 and I'm forced to use mb_send_mail($address, $subject, chunk_split(base64_encode($msg)), $extra_headers); instead of mb_send_mail($address, $subject, $msg, $extra_headers); -- Edit bug report at http://bugs.php.net/?id=21985&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21985&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21985&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21985&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21985&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21985&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21985&r=support Expected behavior: http://bugs.php.net/fix.php?id=21985&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21985&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21985&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21985&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21985&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21985&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21985&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21985&r=gnused
#21984 [Ver]: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works)
ID: 21984 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Date/time related Operating System: SuSE Linux 8.1 PHP Version: 4.3.0 New Comment: Just some into: I have "downgraded" the server to 4.2.3 - now it works fine... Previous Comments: [2003-01-31 11:22:59] [EMAIL PROTECTED] Can I do something against that or do I have to wait for 4.3.1? Regards, Rolf [2003-01-31 10:58:20] [EMAIL PROTECTED] Confirmed with HEAD on Linux. [2003-01-31 08:39:52] [EMAIL PROTECTED] Today is Friday, 31st Jan. On our server with the new PHP 4.3.0, strtotime says "next monday" is "Feb 10th 2003". That is wrong! On our older servers, which have still PHP 4.2.3, the very same script says "Feb 3rd 2003", which is correct. In 4.3.0 you fixed a bug with "calculation of number of week" - maybe that's the problem. Server clocks are syncronized between the servers, so that's not the point :-) Thanks and bye, Rolf -- Edit this bug report at http://bugs.php.net/?id=21984&edit=1
#21886 [Com]: parameters sometimes not submitted
ID: 21886
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: Linux 7.2
PHP Version: 4.3.0
New Comment:
With multiple parameters too, creates trouble. Using 2 parameters,
sometimes only the second one is passed... as the first!
Previous Comments:
[2003-01-26 07:52:28] [EMAIL PROTECTED]
Hi @all,
I have just mentioned a strange behaviour of PHP 4.3.0.
At first of all: I have recompiled my hole config with PHP 4.2.3 and my
program runs - without any change - fine !
Just have a look at the source:
In index2.phtml:
-
$dummy="index2.phtml?step=printchecklist&mode=".$mode."&besuchid=".$besuch_id."&hid=".$form_hid."&sessvalid=".$s_sessvalid;
if ($debug) @error_log("Redirect [origin=checklist] to: ".$dummy,0);
$session->redirectTo($dummy);
-
in my Session-Class:
-
function redirectTo($pathInfo) {
if ($this->debug) @error_log("SESSION [redirectTo]: Parameter:
".$pathInfo,0);
[...]
}
-
and now my error-log:
-
[Sun Jan 26 14:24:43 2003] [error] Redirect [origin=checklist] to:
index2.phtml?step=printchecklist&mode=&besuchid=&hid=16&sessvalid=951227295
[Sun Jan 26 14:24:43 2003] [error] SESSION [redirectTo]: Parameter:
-
The Parameter given to $session->redirectTo will not be recieved by the
function. When I try this several times (my "$dummy" does NOT !!!
change) after the second or the third try it works.
Again - with 4.2.3 and excatly the same config *everything* is fine.
Regards,
Sebastian
--
Edit this bug report at http://bugs.php.net/?id=21886&edit=1
#21984 [Ver]: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works)
ID: 21984 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Date/time related Operating System: SuSE Linux 8.1 PHP Version: 4.3.0 New Comment: Can I do something against that or do I have to wait for 4.3.1? Regards, Rolf Previous Comments: [2003-01-31 10:58:20] [EMAIL PROTECTED] Confirmed with HEAD on Linux. [2003-01-31 08:39:52] [EMAIL PROTECTED] Today is Friday, 31st Jan. On our server with the new PHP 4.3.0, strtotime says "next monday" is "Feb 10th 2003". That is wrong! On our older servers, which have still PHP 4.2.3, the very same script says "Feb 3rd 2003", which is correct. In 4.3.0 you fixed a bug with "calculation of number of week" - maybe that's the problem. Server clocks are syncronized between the servers, so that's not the point :-) Thanks and bye, Rolf -- Edit this bug report at http://bugs.php.net/?id=21984&edit=1
#20551 [NoF->Opn]: Output compression causes segfaults (ob_gzhandler)
ID: 20551
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
Bug Type: Apache related
Operating System: RedHat 7.2
-PHP Version: 4.3.0RC3
+PHP Version: 4.3.0
New Comment:
I now have verified that the bug remains into the release version of
4.3.0. I'll check the php4-STABLE-latest.tar.gz version this weekend.
(Note that with this patch upgrading to v4.3 I no longer see segfaults
in the Apache log!! Sweet!)
Previous Comments:
[2003-01-31 01:00:03] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2003-01-15 20:46:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2002-12-12 15:06:41] [EMAIL PROTECTED]
Reclassifying since it is the Apache module code where the actual
segfaults occur.
Short version: SG(server_context) is not checked for null before
dereferencing it in sapi_apache_header_handler() while it is checked in
other functions.
[2002-12-06 09:30:55] [EMAIL PROTECTED]
Finally.
In file:
sapi/apache/mod_php4.c
The crash is in sapi_apache_header_handler(). This line is apparently
not guaranteed:
request_rec *r = (request_rec *) SG(server_context);
As r is dereferenced and not valid some small percent of the time. It
may be indicative of some other error. Further investigation as to why
needs to be done.
I added a few other checks while tracking this bug down. Here is the
function as I have it now. No more segfaults in the error_log. The line
to note is the check for !r. Also, I don't think it hurts to check for
null in other places (!sapi_header || !sapi_header->header).
/* {{{ sapi_apache_header_handler
*/
int sapi_apache_header_handler(sapi_header_struct *sapi_header,
sapi_headers_struct *sapi_headers TSRMLS_DC)
{
char *header_name, *header_content, *p;
request_rec *r = (request_rec *) SG(server_context);
if (!sapi_header) {
return 0;
}
if (!sapi_header->header) {
return 0;
}
header_name = sapi_header->header;
header_content = strchr(header_name, ':');
if (!header_content || !r) {
efree(sapi_header->header);
return 0;
}
header_name =
estrndup(header_name,header_content-header_name);
if (!header_name){
return 0;
}
do {
header_content++;
} while (*header_content==' ');
if (!strcasecmp(header_name, "Content-Type")) {
r->content_type = pstrdup(r->pool, header_content);
} else if (!strcasecmp(header_name, "Set-Cookie")) {
table_add(r->headers_out, header_name,
header_content);
} else if (sapi_header->replace) {
table_set(r->headers_out, header_name,
header_content);
} else {
table_add(r->headers_out, header_name,
header_content);
efree(header_name);
efree(sapi_header->header);
return 0; /* don't use the default SAPI mechanism, Apache
duplicates this functionality */
}
/* }}} */
[2002-12-05 18:34:16] [EMAIL PROTECTED]
OK, I was able to have gbb attach to one of the 500 children and wait
for a segault. This is version 4.2.3, as this is from our production
site (late at night I'll try and do the same for a full debug version
of 4.3RC2):
Program received signal SIGSEGV, Segmentation fault.
0x080a9b2c in sapi_apache_header_handler ()
(gdb) bt
#0 0x080a9b2c in sapi_apache_header_handler ()
#1 0x080af403 in sapi_add_header_ex ()
#2 0x080b5700 in zif_ob_gzhandler ()
#3 0x08124392 in call_user_function_ex ()
#4 0x080b20f9 in php_end_ob_buffer ()
#5 0x080b23bb in php_end_ob_buffers ()
#6 0x080ac0a7 in php_request_shutdown ()
#7 0x081530d8 in run_cleanups ()
#8 0x08151ec8 in ap_clear_pool ()
#9 0x08151f28 in ap_destroy_pool ()
#10 0x08151e9b in ap_clear_pool ()
#11 0x0815e92b in child_main ()
#12 0x0815ef0b in make_child ()
#13 0x0815f1e9 in perform_idle_server_maintenance ()
#14 0x0815f69a in standalone_main ()
#15 0x0815fc2c in main ()
The remainder of the comments for this repor
#21984 [Opn->Ver]: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works)
ID: 21984 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Date/time related Operating System: SuSE Linux 8.1 PHP Version: 4.3.0 New Comment: Confirmed with HEAD on Linux. Previous Comments: [2003-01-31 08:39:52] [EMAIL PROTECTED] Today is Friday, 31st Jan. On our server with the new PHP 4.3.0, strtotime says "next monday" is "Feb 10th 2003". That is wrong! On our older servers, which have still PHP 4.2.3, the very same script says "Feb 3rd 2003", which is correct. In 4.3.0 you fixed a bug with "calculation of number of week" - maybe that's the problem. Server clocks are syncronized between the servers, so that's not the point :-) Thanks and bye, Rolf -- Edit this bug report at http://bugs.php.net/?id=21984&edit=1
#21600 [Ctl]: assign by reference function call changes variable contents
ID: 21600
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Redhat 7.3, 8
PHP Version: 4.3.0, 5.0.0
New Comment:
I noticed this issue has something to do with the version of bison used
in a build.
Below is just my assumption:
1.28 => works
1.35 => works
1.75 => doesn't work
1.875 => ???
Previous Comments:
[2003-01-23 16:44:49] [EMAIL PROTECTED]
Here is a simular problem - it seem to be a problem with referencing to
values from functions that not themselfs return reference.
name = $name;
$wiefewfjwefjwefwef =& $this->getName(); // <-- this line
destroys $this->name and eventually crashes apache+php
}
function /*&*/ getName() {
return $this->name;
}
}
$kent =& new Person('Kent');
echo ''; print_r($kent); echo '';
echo 'PersonName: "' . $kent->getName() . '"';
?>
[2003-01-14 00:52:07] [EMAIL PROTECTED]
update version
[2003-01-13 19:42:44] [EMAIL PROTECTED]
I'm marking this critical because the provided script works fine on the
previous released versions.
[2003-01-13 01:21:08] [EMAIL PROTECTED]
backtrace (with php-5.0.0-dev):
#0 0x40749e49 in __sbrk (increment=1515880448) at
../sysdeps/generic/sbrk.c:33
#1 0x406e9d3c in __default_morecore (increment=1515880448)
at ../sysdeps/generic/morecore.c:47
#2 0x406e676d in chunk_alloc (ar_ptr=0x40798520, nb=1515878480)
at malloc.c:2583
#3 0x406e60bc in __libc_malloc (bytes=1515878476) at malloc.c:2817
#4 0x08256b63 in zend_mm_add_memory_block (heap=0x8333748,
block_size=1515878476) at
/dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:143
#5 0x08256de6 in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:236
#6 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#7 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#8 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#9 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#10 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#11 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#12 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
(last frame continues atleast 15.000 times)
Derick
[2003-01-12 15:56:50] [EMAIL PROTECTED]
Verified with HEAD(ZE2) and PHP_4_3(ZE1).
The provided script causes segmentation fault.
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/21600
--
Edit this bug report at http://bugs.php.net/?id=21600&edit=1
#21981 [Com]: MYSQL_CLIENT_SSL constant is undefined
ID: 21981
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: MySQL related
Operating System: Windows NT 5.1
PHP Version: 4CVS-2003-01-31 (stable)
New Comment:
No,
it's still in. Please follow the link mentioned above. There you'll
find this passage:
The client_flags parameter can be a combination of the constants
MYSQL_CLIENT_SSL, MYSQL_CLIENT_COMPRESS, MYSQL_CLIENT_IGNORE_SPACE or
MYSQL_CLIENT_INTERACTIVE.
Thanks for the information, could you tell when SLL support will be
enabled?
Previous Comments:
[2003-01-31 10:07:19] [EMAIL PROTECTED]
s/SSH/SSL
[2003-01-31 09:55:53] [EMAIL PROTECTED]
SSH-Client constant was removed from the documentation (en) ~5 months
ago. PHP's current mysql extension doesn't support SSH connects.
[2003-01-31 07:36:42] [EMAIL PROTECTED]
My Config:
Windows NT 5.1 ("XP")
Apache 2.0.44
PHP 4.3.1-CVS (stable)
MySQL 4.0.9-gamma-max-nt
I tried to connect to a MySQL 4.0.9 server using SSL encryption.
This resulted in a warning because the constant "MYSQL_CLIENT_SSL" was
not defined, unlike to what the documentation says:
http://www.php.net/manual/en/function.mysql-connect.php
A look into the phpinfo() output told me, that your Win32 binary
distributions seem to be compiled with the MySQL client API version
3.23.49.
As far as I know, MySQL supports SSL since 4.0.0 so your client API
appears obsolete to me.
--
Edit this bug report at http://bugs.php.net/?id=21981&edit=1
#14547 [NoF->Opn]: Informix as shared module libtool rpath problem
ID: 14547 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Informix related Operating System: RH Linux 7.1 PHP Version: 4.1.0 New Comment: This got listed as no-feedback? What gives? Previous Comments: [2002-10-21 10:02:57] [EMAIL PROTECTED] /bin/sh /home/mike/php-4.2.3/libtool --silent --mode=link gcc -I. -I/home/mike/php-4.2.3/ext/informix -I/home/mike/php-4.2.3/main -I/home/mike/php-4.2.3 -I/home/mike/php-4.2.3/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.3/ext/mysql/libmysql -I/home/mike/php-4.2.3/ext/xml/expat -I/home/mike/php-4.2.3/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.3/modules ifx.lo -R/home/mike/php-4.2.3/ext/informix -L/home/mike/php-4.2.3/ext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lifglx Made it work, I had to remove -lphpifx and add absolute paths to some of the stuff. I don't understand why this can't be fixed, the bug and fix have been documented for months now, what gives? 1. Change makefile to use absolute paths for libtool. 2. Remove -lphpfix from the buld line. [2002-10-21 09:45:19] [EMAIL PROTECTED] ./configure --with-informix=shared Still fails, with: /php-4.2.3 -I/home/mike/php-4.2.3/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.3/ext/mysql/libmysql -I/home/mike/php-4.2.3/ext/xml/expat -I/home/mike/php-4.2.3/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.3/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 This can be fixed easily by hand, but I don't know how to fix it with the configure stuff. It is still a bug. [2002-07-16 01:00:08] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-06-16 00:31:43] [EMAIL PROTECTED] Works just fine as shared too. Please let us know if the snapshot works for you or not. [2002-06-15 23:56:08] [EMAIL PROTECTED] Please try compiling it as shared. I'll try the same from the snapshot. 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/14547 -- Edit this bug report at http://bugs.php.net/?id=14547&edit=1
#21981 [Csd]: MYSQL_CLIENT_SSL constant is undefined
ID: 21981
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: MySQL related
Operating System: Windows NT 5.1
PHP Version: 4CVS-2003-01-31 (stable)
New Comment:
s/SSH/SSL
Previous Comments:
[2003-01-31 09:55:53] [EMAIL PROTECTED]
SSH-Client constant was removed from the documentation (en) ~5 months
ago. PHP's current mysql extension doesn't support SSH connects.
[2003-01-31 07:36:42] [EMAIL PROTECTED]
My Config:
Windows NT 5.1 ("XP")
Apache 2.0.44
PHP 4.3.1-CVS (stable)
MySQL 4.0.9-gamma-max-nt
I tried to connect to a MySQL 4.0.9 server using SSL encryption.
This resulted in a warning because the constant "MYSQL_CLIENT_SSL" was
not defined, unlike to what the documentation says:
http://www.php.net/manual/en/function.mysql-connect.php
A look into the phpinfo() output told me, that your Win32 binary
distributions seem to be compiled with the MySQL client API version
3.23.49.
As far as I know, MySQL supports SSL since 4.0.0 so your client API
appears obsolete to me.
--
Edit this bug report at http://bugs.php.net/?id=21981&edit=1
#21981 [Opn->Csd]: MYSQL_CLIENT_SSL constant is undefined
ID: 21981
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: MySQL related
Operating System: Windows NT 5.1
PHP Version: 4CVS-2003-01-31 (stable)
New Comment:
SSH-Client constant was removed from the documentation (en) ~5 months
ago. PHP's current mysql extension doesn't support SSH connects.
Previous Comments:
[2003-01-31 07:36:42] [EMAIL PROTECTED]
My Config:
Windows NT 5.1 ("XP")
Apache 2.0.44
PHP 4.3.1-CVS (stable)
MySQL 4.0.9-gamma-max-nt
I tried to connect to a MySQL 4.0.9 server using SSL encryption.
This resulted in a warning because the constant "MYSQL_CLIENT_SSL" was
not defined, unlike to what the documentation says:
http://www.php.net/manual/en/function.mysql-connect.php
A look into the phpinfo() output told me, that your Win32 binary
distributions seem to be compiled with the MySQL client API version
3.23.49.
As far as I know, MySQL supports SSL since 4.0.0 so your client API
appears obsolete to me.
--
Edit this bug report at http://bugs.php.net/?id=21981&edit=1
#20926 [Opn->Csd]: libmcrypt error in configure
ID: 20926
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: mcrypt related
Operating System: NetBSD-1.5.2
PHP Version: 4.3.0RC2
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-01-29 14:56:34] [EMAIL PROTECTED]
hi guys,
just in case anything goes on out there:
I GOT IT!
short description: download libtool and install it.
this will make php-configure recognize -lmcrypt as valid.
story:
the REAL problem was not having an error while compiling mcrypt with
php, it was more likely that i did not have the libtool-library
libltdl.* on my system!
i downloaded libtool-1.4.3, configured it and ran a make install and
THEN php was fine with libmcrypt!
the only thing i've to say is: PLEASE, if you add a -ltdl within any
configure script, let the configure script CHECK FOR IT and generate
ERROR messages to the user if it's not found on the system. i spent
very much time (yes, my fault but) to figure out this stuff! this
would not have occurred if your configure script told me that we need
ltdl to compile our stuff!
thx for support and cu,
md.
ps: you can close my bug-reports.
[2003-01-29 05:05:21] [EMAIL PROTECTED]
hi guys,
as told in bug 21936, i have similar problems with php-4.3.0 release
(NOT an RC!) and libmcrypt-2.5.6.
in this case, i do not see the solution.
plz help to configure & compile,
br, md.
ps: sorry, this comment post went to the wrong bug before...
don't know how that happened... obv. my fault ;-)
[2003-01-02 18:45:22] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-12-11 13:10:22] [EMAIL PROTECTED]
hmm, :-) Patching configure is of little use, it's generated from
config.m4 files. It would be nice if you could try to fix
ext/mcrypt/config.m4, but I doubt it's possible.
After you modify config.m4's dont forget to rm configure && ./buildconf
It works all fine here, so I cant really help you.
Derick
[2002-12-11 13:04:24] [EMAIL PROTECTED]
Actually, the problem is here:
--- configure~ Wed Nov 27 15:02:21 2002
+++ configure Wed Dec 11 13:57:27 2002
@@ -47410,16 +47410,14 @@
save_old_LDFLAGS=$LDFLAGS
- LDFLAGS="
--L$MCRYPT_DIR/lib -lltdl
- $LDFLAGS"
+ LDFLAGS="$LDFLAGS"
echo "$as_me:$LINENO: checking for mcrypt_module_open in -lmcrypt"
>&5
echo $ECHO_N "checking for mcrypt_module_open in -lmcrypt... $ECHO_C"
>&6
if test "${ac_cv_lib_mcrypt_mcrypt_module_open+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
ac_check_lib_save_LIBS=$LIBS
-LIBS="-lmcrypt $LIBS"
+LIBS="-lmcrypt -lltdl $LIBS"
cat >conftest.$ac_ext <<_ACEOF
#line $LINENO "configure"
#include "confdefs.h"
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/20926
--
Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#14013 [Com]: ocibindbyname strips trailing spaces
ID: 14013
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: OCI8 related
Operating System: Linux 2.2, Solaris 2.6
PHP Version: 4.0.6
New Comment:
It seems, that I have the same problem using PHP 4.3.0 on Apache 1.3.22
with Oracle 8.1.7:
When I use a OciBindByName, the string is trimed at the end. This small
program uses the DUAL from Oracle just to return the input:
$conn = OciLogon ("x","y","z");
$val = " X X "; // last letter is a " " (blank)
// direct way without a bind variable
$stm1 = OciParse($conn, "select '".$val."' from dual");
OciExecute($stm1);
OciFetch($stm1);
echo "", OciResult($stm1, 1), "\n";
// now using a bind variable:
$stm2 = OciParse($conn, "select :input from dual");
OciBindByName($stm2, ":input", &$val, 10);
OciExecute($stm2);
OciFetch($stm2);
echo "", OciResult($stm2, 1), "\n";
OciLogoff($conn);
The output is:
X X
X X
But I want to get the same output for the direct way and when I use a
bind variable.
Thank you for any idea how to get the string with tailing spaces right
into Oracle using a bind variable.
Best wishes,
Jens
Previous Comments:
[2002-04-13 08:58:13] [EMAIL PROTECTED]
try storing in a varchar2 firld, if you use CHAR oracle will trim
traing spaces.
[2001-11-11 06:49:19] [EMAIL PROTECTED]
Erm, yeah, that's supposed to be '$id = 666;'.
[2001-11-11 03:28:34] [EMAIL PROTECTED]
When inserting text using named binds, PHP will strip trailing spaces.
The same query on the same database using the same Oracle client
libraries. (All Oracle 8.1.6)
$db = ocilogon("u", "p", "sid");
$st = ociparse($db, "insert into test values (:id, :text)");
ocibindbyname($st, ":text", &$text, 2000);
ocibindbyname($st, ":id", &$id, 22);
$text = " this line has spaces ";
$node_id = 666;
ociexecute($st);
--
Edit this bug report at http://bugs.php.net/?id=14013&edit=1
#21908 [Com]: File upload problems beginning in 4.3.0
ID: 21908 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *General Issues Operating System: NetBSD-1.5.2 PHP Version: 4.3.0 New Comment: I also expirienced this problem. In my case I had "file_uploads = Off" in php.ini and then "php_flag file_uploads on" for every virtual host that require upload. That works perfectly in 4.2.3. According to phpinfo() setting private flag have no effect for this option in 4.3.0. I was forced to enable file uploads on system level in php.ini to solve the problem. Previous Comments: [2003-01-29 09:34:37] [EMAIL PROTECTED] We are running both the apache module and the cgi. The problem is present in both. However, it was not present in 4.2.3 (both the apache module and the standalone version). [2003-01-29 00:02:07] [EMAIL PROTECTED] And is PHP compiled as module in Apache or are you running it as CGI? [2003-01-28 12:47:52] [EMAIL PROTECTED] There is no error message from that script. It fails silently. We are using Apache-1.3.27. Thanks for your help. [2003-01-27 17:09:01] [EMAIL PROTECTED] What apache version? What is the output of your script? [2003-01-27 12:38:44] [EMAIL PROTECTED] I am running the following code in php-4.3.0: _FILES[portrait]: \n"; print_r($portrait); print ""; $portrait = $_GLOBALS["portrait"]; print "_FILES[portrait]: \n"; print_r($portrait); print $_FILES["portrait"]["error"]; print ""; ?> The file does not appear to be uploaded. However, with php-4.2.3, everything works fine. I have confirmed that both file_uploads and register_globals are on. This problem occurs in both the apache module and the standalone version. is_uploaded_file() also reports failure with php-4.3.0. -- Edit this bug report at http://bugs.php.net/?id=21908&edit=1
#21983 [Fbk->Opn]: Php SegFault
ID: 21983
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: linux
PHP Version: 4.3.0
New Comment:
a much simple script to reproduce the crash , with a backtrace:
dom=& $dom;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
return $this->e_resolver;
}
}
$dom=domxml_new_doc('1.0');
$resolver=new resolver($dom,
$HTTP_GET_VARS['nameserver'],$HTTP_GET_VARS['domain'],"");
$resolver=$resolver->write_xml();
$servers=array($int_eth0, $int_eth1);
$network=$dom->create_element('network');
$network->append_child($resolver);
?>
Previous Comments:
[2003-01-31 08:44:47] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2003-01-31 08:37:20] [EMAIL PROTECTED]
$php file.php
Segmentation fault
$
---file.php---
dom=& $dom;
$this->basename=$basename;
$this->network=$network;
$this->proxy=$proxy;
}
function &write_xml () {
$this->e_zactivbox=$this->dom->create_element('zactivbox');
$this->e_zactivbox->set_attribute('basename', $this->basename);
$this->e_zactivbox->append_child($network);
$this->e_zactivbox->append_child($proxy);
return $this->e_zactivbox;
}
}
class network {
var $servers; //array of server
var $route;
var $resolver;
var $dom;
var $e_network;
function network (&$dom, $servers, $route, $resolver) {
$this->dom=& $dom;
$this->servers=$servers;
$this->route=$route;
$this->resolver=$resolver;
}
function &write_xml() {
$this->e_network=$this->dom->create_element('network');
foreach($this->servers as $key => $server)
{
$this->e_network->append_child($server);
}
$this->e_network->append_child($this->route);
$this->e_network->append_child($this->resolver);
return $this->e_network;
}
}
class resolver {
var $domain;
var $search;
var $nameserver;
var $dom;
var $e_resolver;
function resolver (&$dom, $nameserver, $domain='', $search='') {
$this->dom=& $dom;
$this->domain=$domain;
$this->search=$search;
$this->nameserver=$nameserver;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
$e_domain=$this->dom->create_element('domain');
$t_domain=$this->dom->create_text_node($this->domain);
$e_domain->append_child($t_domain);
$this->e_resolver->append_child($e_domain);
$e_search=$this->dom->create_element('search');
$t_search=$this->dom->create_text_node($this->search);
$e_search->append_child($t_search);
$this->e_resolver->append_child($e_search);
$t_nameserver=$this->dom->create_text_node($this->nameserver);
$e_nameserver=$this->dom->create_element('nameserver');
$e_nameserver->append_child($t_nameserver);
$this->e_resolver->append_child($e_nameserver);
return $this->e_resolver;
}
}
class route {
var $destination;
var $iface;
var $ip;
var $dom;
var $e_route;
function route (&$dom, $destination, $ip, $iface) {
$this->dom=& $dom;
$this->destination=$destination;
$this->ip=$ip;
$this->iface=$iface;
}
function &write_xml() {
$this->e_route=$this->dom->create_element('route');
$this->e_route->set_attribute('destination', $this->destination);
$e_iface=$this->dom->create_element('iface');
$t_iface=$this->dom->create_text_node($this->iface);
$e_iface->append_child($t_iface);
#21983 [Opn->Fbk]: Php SegFault
ID: 21983
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: linux
PHP Version: 4.3.0
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Previous Comments:
[2003-01-31 08:37:20] [EMAIL PROTECTED]
$php file.php
Segmentation fault
$
---file.php---
dom=& $dom;
$this->basename=$basename;
$this->network=$network;
$this->proxy=$proxy;
}
function &write_xml () {
$this->e_zactivbox=$this->dom->create_element('zactivbox');
$this->e_zactivbox->set_attribute('basename', $this->basename);
$this->e_zactivbox->append_child($network);
$this->e_zactivbox->append_child($proxy);
return $this->e_zactivbox;
}
}
class network {
var $servers; //array of server
var $route;
var $resolver;
var $dom;
var $e_network;
function network (&$dom, $servers, $route, $resolver) {
$this->dom=& $dom;
$this->servers=$servers;
$this->route=$route;
$this->resolver=$resolver;
}
function &write_xml() {
$this->e_network=$this->dom->create_element('network');
foreach($this->servers as $key => $server)
{
$this->e_network->append_child($server);
}
$this->e_network->append_child($this->route);
$this->e_network->append_child($this->resolver);
return $this->e_network;
}
}
class resolver {
var $domain;
var $search;
var $nameserver;
var $dom;
var $e_resolver;
function resolver (&$dom, $nameserver, $domain='', $search='') {
$this->dom=& $dom;
$this->domain=$domain;
$this->search=$search;
$this->nameserver=$nameserver;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
$e_domain=$this->dom->create_element('domain');
$t_domain=$this->dom->create_text_node($this->domain);
$e_domain->append_child($t_domain);
$this->e_resolver->append_child($e_domain);
$e_search=$this->dom->create_element('search');
$t_search=$this->dom->create_text_node($this->search);
$e_search->append_child($t_search);
$this->e_resolver->append_child($e_search);
$t_nameserver=$this->dom->create_text_node($this->nameserver);
$e_nameserver=$this->dom->create_element('nameserver');
$e_nameserver->append_child($t_nameserver);
$this->e_resolver->append_child($e_nameserver);
return $this->e_resolver;
}
}
class route {
var $destination;
var $iface;
var $ip;
var $dom;
var $e_route;
function route (&$dom, $destination, $ip, $iface) {
$this->dom=& $dom;
$this->destination=$destination;
$this->ip=$ip;
$this->iface=$iface;
}
function &write_xml() {
$this->e_route=$this->dom->create_element('route');
$this->e_route->set_attribute('destination', $this->destination);
$e_iface=$this->dom->create_element('iface');
$t_iface=$this->dom->create_text_node($this->iface);
$e_iface->append_child($t_iface);
$this->e_route->append_child($e_iface);
$e_ip=$this->dom->create_element('ip');
$t_ip=$this->dom->create_text_node($this->ip);
$e_ip->append_child($t_ip);
$this->e_route->append_child($e_ip);
return $this->e_route;
}
}
class interface {
var $iface;
var $ip;
var $broadcast;
var $netmask;
var $mode;
var $position;
var $type;
var $dom;
var $e_interface;
function &interface (&$dom, $iface, $ip, $broadcast, $netmask,
$mode='', $position='', $type=
#21984 [NEW]: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works)
From: [EMAIL PROTECTED] Operating system: SuSE Linux 8.1 PHP version: 4.3.0 PHP Bug Type: Date/time related Bug description: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works) Today is Friday, 31st Jan. On our server with the new PHP 4.3.0, strtotime says "next monday" is "Feb 10th 2003". That is wrong! On our older servers, which have still PHP 4.2.3, the very same script says "Feb 3rd 2003", which is correct. In 4.3.0 you fixed a bug with "calculation of number of week" - maybe that's the problem. Server clocks are syncronized between the servers, so that's not the point :-) Thanks and bye, Rolf -- Edit bug report at http://bugs.php.net/?id=21984&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21984&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21984&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21984&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21984&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21984&r=support Expected behavior: http://bugs.php.net/fix.php?id=21984&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21984&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21984&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21984&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21984&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21984&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21984&r=gnused
#21983 [NEW]: Php SegFault
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: Php SegFault
$php file.php
Segmentation fault
$
---file.php---
dom=& $dom;
$this->basename=$basename;
$this->network=$network;
$this->proxy=$proxy;
}
function &write_xml () {
$this->e_zactivbox=$this->dom->create_element('zactivbox');
$this->e_zactivbox->set_attribute('basename', $this->basename);
$this->e_zactivbox->append_child($network);
$this->e_zactivbox->append_child($proxy);
return $this->e_zactivbox;
}
}
class network {
var $servers; //array of server
var $route;
var $resolver;
var $dom;
var $e_network;
function network (&$dom, $servers, $route, $resolver) {
$this->dom=& $dom;
$this->servers=$servers;
$this->route=$route;
$this->resolver=$resolver;
}
function &write_xml() {
$this->e_network=$this->dom->create_element('network');
foreach($this->servers as $key => $server)
{
$this->e_network->append_child($server);
}
$this->e_network->append_child($this->route);
$this->e_network->append_child($this->resolver);
return $this->e_network;
}
}
class resolver {
var $domain;
var $search;
var $nameserver;
var $dom;
var $e_resolver;
function resolver (&$dom, $nameserver, $domain='', $search='') {
$this->dom=& $dom;
$this->domain=$domain;
$this->search=$search;
$this->nameserver=$nameserver;
}
function &write_xml() {
$this->e_resolver=$this->dom->create_element('resolver');
$e_domain=$this->dom->create_element('domain');
$t_domain=$this->dom->create_text_node($this->domain);
$e_domain->append_child($t_domain);
$this->e_resolver->append_child($e_domain);
$e_search=$this->dom->create_element('search');
$t_search=$this->dom->create_text_node($this->search);
$e_search->append_child($t_search);
$this->e_resolver->append_child($e_search);
$t_nameserver=$this->dom->create_text_node($this->nameserver);
$e_nameserver=$this->dom->create_element('nameserver');
$e_nameserver->append_child($t_nameserver);
$this->e_resolver->append_child($e_nameserver);
return $this->e_resolver;
}
}
class route {
var $destination;
var $iface;
var $ip;
var $dom;
var $e_route;
function route (&$dom, $destination, $ip, $iface) {
$this->dom=& $dom;
$this->destination=$destination;
$this->ip=$ip;
$this->iface=$iface;
}
function &write_xml() {
$this->e_route=$this->dom->create_element('route');
$this->e_route->set_attribute('destination', $this->destination);
$e_iface=$this->dom->create_element('iface');
$t_iface=$this->dom->create_text_node($this->iface);
$e_iface->append_child($t_iface);
$this->e_route->append_child($e_iface);
$e_ip=$this->dom->create_element('ip');
$t_ip=$this->dom->create_text_node($this->ip);
$e_ip->append_child($t_ip);
$this->e_route->append_child($e_ip);
return $this->e_route;
}
}
class interface {
var $iface;
var $ip;
var $broadcast;
var $netmask;
var $mode;
var $position;
var $type;
var $dom;
var $e_interface;
function &interface (&$dom, $iface, $ip, $broadcast, $netmask, $mode='',
$position='', $type='') {
$this->dom=& $dom;
$this->iface=$iface;
$this->ip=$ip;
$this->broadcast=$broadcast;
$this->netmask=$netmask;
$this->mode=$mode;
$this->position=$position;
$this->type=$type;
}
function &write_xml() {
$this->e_interface=$this->dom->create_element('interface');
if ( $this->mode != '' )
{
$this->e_interface->set_attribute('mode', $this->mode);
}
#21982 [NEW]: imap_fetchstructure crashes php on apache
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.2.2 PHP Bug Type: IMAP related Bug description: imap_fetchstructure crashes php on apache imap_fetchstructure crashes PHP on Apache when try to read mailbox witch such message header: == Return-Path: <[EMAIL PROTECTED]> X-Sieve: cmu-sieve 2.0 Received: from vilnius.balt.net (vilnius.balt.net [195.14.170.14]) by calypso.bi.lt (Postfix) with SMTP id 311311B32A5 for <[EMAIL PROTECTED]>; Tue, 14 Jan 2003 15:56:37 +0200 (GMT-2) Received: (qmail 31283 invoked from network); 14 Jan 2003 13:56:28 - Received: from ip-195-14-171-1.bnk.lt (HELO DARIUS) (195.14.171.1) by vilnius.balt.net with SMTP; 14 Jan 2003 13:56:28 - Date: Tue, 14 Jan 2003 16:00:52 +0100 From: InfoUltra <[EMAIL PROTECTED]> X-Mailer: The Bat! (v1.41) UNREG / CD5BF9353B3B7091 Reply-To: InfoUltra <[EMAIL PROTECTED]> X-Priority: 3 (Normal) Message-ID: <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], vandad"@socmin.lt>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAI
#21973 [Opn->Fbk]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: I misunderstood the problem apparently, sorry for that. Anyway, in what version of PHP did LDAP configure work without any patches? Is the only problem really that we check that the actual library _file_ exists? Better way of course would be to use PHP_CHECK_LIBRARY macro always and not do the filesystem checks at all, like Marcus suggested..? Previous Comments: [2003-01-31 06:19:33] [EMAIL PROTECTED] > we would have to change all configure files. Maybe huge rafts of PHP use the lib name convention, but for some reason it doesn't matter -- those parts of PHP work in my context anyway. And yes, some modules compile and some don't. Some used to and now they don't. >From my point of view: A) Why it would be okay that a module like ldap worked two/three months ago but does not configure correctly today. Surely this would considered to be regression. B) Why other software doesn't stumble during configuration but PHP does. Surely this is a problem with PHP. Maybe it's a case of "gosh, this is extensively wrong", but that doesn't make the problem bogus. C) I suspect that PHP would compile and run correctly if I comment out the 'exit' commands in configure. Then, if the ONLY reason that PHP doesn't compile is that configure stumbles -- not that any libraries are missing or can't already be found by the compiler -- surely that is because the implementation of 'configure' is wrong. It's as though...configure doesn't need to be made to work differently in as much as it may be sufficient if it just stopped exiting prematurely. After doing some experimentation with this, maybe I have to resubmit this bug for each affected module? Gah. Alternatively, maybe I can post to php-dev and an existing developer can pick up this matter in general (which is what I'd hoped would happen with this report)? [2003-01-31 05:28:14] [EMAIL PROTECTED] If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). [2003-01-31 05:11:00] [EMAIL PROTECTED] Re: [EMAIL PROTECTED] [Sorry, didn't get around to reading your new message until after sending the followup that I started prior to you message.] Woah! Is this part of a concerted effort to eliminate support for modern platforms? Is that why LP64 64-bit compatibility is so broken and the Zend engine and PHP modules are drifting away from C-code portability? Is this part due to a move by Zend to only support commercially-associated hardware or something? Some missing details here. I'm not sure what status to believe this bug is at. I think "Open". It's been changed to "Bogus" twice but from what you've said, it sounds like "Won't Fix" (I don't have that option in the bug tracking interface, perhaps you do?). Of 147 packages that I compile on the same architecture, and who-knows-how-many-more that come in packages, why is PHP avoiding support? Won't it be detrimental if operating system vendors have to heavily patch/port PHP in order to keep it working on their platforms (in order to maintain viability of those platforms)? Is there an arbitration board or core developer group that I can speak to about this? Sounds like an off-list matter to begin with. [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform
#21981 [NEW]: MYSQL_CLIENT_SSL constant is undefined
From: [EMAIL PROTECTED]
Operating system: Windows NT 5.1
PHP version: 4CVS-2003-01-31 (stable)
PHP Bug Type: MySQL related
Bug description: MYSQL_CLIENT_SSL constant is undefined
My Config:
Windows NT 5.1 ("XP")
Apache 2.0.44
PHP 4.3.1-CVS (stable)
MySQL 4.0.9-gamma-max-nt
I tried to connect to a MySQL 4.0.9 server using SSL encryption.
This resulted in a warning because the constant "MYSQL_CLIENT_SSL" was not
defined, unlike to what the documentation says:
http://www.php.net/manual/en/function.mysql-connect.php
A look into the phpinfo() output told me, that your Win32 binary
distributions seem to be compiled with the MySQL client API version
3.23.49.
As far as I know, MySQL supports SSL since 4.0.0 so your client API
appears obsolete to me.
--
Edit bug report at http://bugs.php.net/?id=21981&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21981&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21981&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21981&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21981&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21981&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21981&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21981&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21981&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21981&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21981&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21981&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21981&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21981&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21981&r=gnused
#21979 [Bgs]: mistake of operator "if"
ID: 21979
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: windows 2000
PHP Version: 4.3.0
New Comment:
erm, where in the manual did you see the first version?
Previous Comments:
[2003-01-31 06:41:42] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
= is not the same as ==
[2003-01-31 06:36:42] [EMAIL PROTECTED]
can't work a script
$r=0;
if ($r=1) {$a=1;} //comparison on equal
else {$a=0;}
print "Result=$a";
i see always "Result=1"
but can work a script
$r=0;
if ($r==1) {$a=1;} //comparison on identical
else {$a=0;}
print "Result=$a";
i did see manual of PHP what must work both ways
--
Edit this bug report at http://bugs.php.net/?id=21979&edit=1
#21979 [Opn->Bgs]: mistake of operator "if"
ID: 21979
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: windows 2000
PHP Version: 4.3.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
= is not the same as ==
Previous Comments:
[2003-01-31 06:36:42] [EMAIL PROTECTED]
can't work a script
$r=0;
if ($r=1) {$a=1;} //comparison on equal
else {$a=0;}
print "Result=$a";
i see always "Result=1"
but can work a script
$r=0;
if ($r==1) {$a=1;} //comparison on identical
else {$a=0;}
print "Result=$a";
i did see manual of PHP what must work both ways
--
Edit this bug report at http://bugs.php.net/?id=21979&edit=1
#21979 [NEW]: mistake of operator "if"
From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version: 4.3.0
PHP Bug Type: Scripting Engine problem
Bug description: mistake of operator "if"
can't work a script
$r=0;
if ($r=1) {$a=1;} //comparison on equal
else {$a=0;}
print "Result=$a";
i see always "Result=1"
but can work a script
$r=0;
if ($r==1) {$a=1;} //comparison on identical
else {$a=0;}
print "Result=$a";
i did see manual of PHP what must work both ways
--
Edit bug report at http://bugs.php.net/?id=21979&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21979&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21979&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21979&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21979&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21979&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21979&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21979&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21979&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21979&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21979&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21979&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21979&r=gnused
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: > we would have to change all configure files. Maybe huge rafts of PHP use the lib name convention, but for some reason it doesn't matter -- those parts of PHP work in my context anyway. And yes, some modules compile and some don't. Some used to and now they don't. >From my point of view: A) Why it would be okay that a module like ldap worked two/three months ago but does not configure correctly today. Surely this would considered to be regression. B) Why other software doesn't stumble during configuration but PHP does. Surely this is a problem with PHP. Maybe it's a case of "gosh, this is extensively wrong", but that doesn't make the problem bogus. C) I suspect that PHP would compile and run correctly if I comment out the 'exit' commands in configure. Then, if the ONLY reason that PHP doesn't compile is that configure stumbles -- not that any libraries are missing or can't already be found by the compiler -- surely that is because the implementation of 'configure' is wrong. It's as though...configure doesn't need to be made to work differently in as much as it may be sufficient if it just stopped exiting prematurely. After doing some experimentation with this, maybe I have to resubmit this bug for each affected module? Gah. Alternatively, maybe I can post to php-dev and an existing developer can pick up this matter in general (which is what I'd hoped would happen with this report)? Previous Comments: [2003-01-31 05:28:14] [EMAIL PROTECTED] If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). [2003-01-31 05:11:00] [EMAIL PROTECTED] Re: [EMAIL PROTECTED] [Sorry, didn't get around to reading your new message until after sending the followup that I started prior to you message.] Woah! Is this part of a concerted effort to eliminate support for modern platforms? Is that why LP64 64-bit compatibility is so broken and the Zend engine and PHP modules are drifting away from C-code portability? Is this part due to a move by Zend to only support commercially-associated hardware or something? Some missing details here. I'm not sure what status to believe this bug is at. I think "Open". It's been changed to "Bogus" twice but from what you've said, it sounds like "Won't Fix" (I don't have that option in the bug tracking interface, perhaps you do?). Of 147 packages that I compile on the same architecture, and who-knows-how-many-more that come in packages, why is PHP avoiding support? Won't it be detrimental if operating system vendors have to heavily patch/port PHP in order to keep it working on their platforms (in order to maintain viability of those platforms)? Is there an arbitration board or core developer group that I can speak to about this? Sounds like an off-list matter to begin with. [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe an
#21978 [NEW]: bbc: send twice
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4CVS-2003-01-31 (stable) PHP Bug Type: *Mail Related Bug description: bbc: send twice I have got the same problem repoted here #21036 I'm using the last CVS of 31-01-03 but still have problem. When I use bbc field, php send mail twice to the recipient, this don't happen in to: and cc: recipent field. Here the debug of my mail server : 01/31/03 12:16:46 ID 1732 - HELO WWWSWZ\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ ( IP: 127.0.0.1 ) has connected to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - MAIL FROM:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - [EMAIL PROTECTED] is sending a message to the mail server 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:<[EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - RCPT TO:< [EMAIL PROTECTED]>\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - DATA\0D\0A 01/31/03 12:16:46 ID 1732 - 354 Start mail input; end with .\0D\0A 01/31/03 12:16:46 ID 1732 - Date: Fri, 31 Jan 2003 12:16:46 +0100\0D\0A 01/31/03 12:16:46 ID 1732 - From: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - Subject: La Newsletter di Software Zone Italia\0D\0A 01/31/03 12:16:46 ID 1732 - To: [EMAIL PROTECTED]\0D\0A 01/31/03 12:16:46 ID 1732 - MIME-Version: 1.0Content-type: text/html; charset\3Diso-8859-1\0D\0A 01/31/03 12:16:46 ID 1732 - \0D\0A 01/31/03 12:16:46 ID 1732 - ciao\0D\0A 01/31/03 12:16:46 ID 1732 - .\0D\0A 01/31/03 12:16:46 ID 1732 - 250 Requested mail action okay, completed\0D\0A 01/31/03 12:16:46 ID 1732 - QUIT\0D\0A 01/31/03 12:16:46 ID 1732 - 221 Service closing transmission channel\0D\0A 01/31/03 12:16:46 ID 1732 - WWWSWZ has finished delivering messages to the mail server A message to the address bcc: [EMAIL PROTECTED] has been sent twice. -- Edit bug report at http://bugs.php.net/?id=21978&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21978&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21978&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21978&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21978&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21978&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21978&r=support Expected behavior: http://bugs.php.net/fix.php?id=21978&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21978&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21978&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21978&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21978&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21978&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21978&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21978&r=gnused
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). Previous Comments: [2003-01-31 05:11:00] [EMAIL PROTECTED] Re: [EMAIL PROTECTED] [Sorry, didn't get around to reading your new message until after sending the followup that I started prior to you message.] Woah! Is this part of a concerted effort to eliminate support for modern platforms? Is that why LP64 64-bit compatibility is so broken and the Zend engine and PHP modules are drifting away from C-code portability? Is this part due to a move by Zend to only support commercially-associated hardware or something? Some missing details here. I'm not sure what status to believe this bug is at. I think "Open". It's been changed to "Bogus" twice but from what you've said, it sounds like "Won't Fix" (I don't have that option in the bug tracking interface, perhaps you do?). Of 147 packages that I compile on the same architecture, and who-knows-how-many-more that come in packages, why is PHP avoiding support? Won't it be detrimental if operating system vendors have to heavily patch/port PHP in order to keep it working on their platforms (in order to maintain viability of those platforms)? Is there an arbitration board or core developer group that I can speak to about this? Sounds like an off-list matter to begin with. [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe and ask them to change their software because PHP has shown us how it should be done. > What is left could be the fact that you used "libpng12" and > i am not quite sure if we want to search for all versions since there > should be links named libpng. whatever that point to the specific > version (thats different from db-n where we search for a specific > version). libpng chooses libpng12 (as described in its docs). But I do seem to have symlinks using the name libpng rather than libpng12, as you say. Sorry for the confusion! My fault for not being particularly familiar with libpng. Anyway, in my eyes my original bug report stands, including my comment that other configuration steps, such as for LDAP, are broken. Hmm, looking at some live pages right now, LDAP compiled in fine with PHP 4.3.0 pre-release CVS. Although I had to patch PHP extensively to make it install, load, and work correctly, I don't remember having to patch anything in the configure script. Then again, my memory does have many faults. ...pause to wait for fresh copies of PHP to run 'configure'... Yes, 4.3.0 release seems to report an error when trying to find ldap whereas 4.3.0 CVS (unknown date, I could find out though) seems fine. I may have to leave this matter overnight since it is 7pm in my timezone. (Which is extremely different to whatever timezone -- apparently not UTC -- that the bugs.php.net interface seems to use :) [2003-01-31 04:18:23] [EMAIL PROTECTED] The way this works, works for 99.99% of users
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Re: [EMAIL PROTECTED] [Sorry, didn't get around to reading your new message until after sending the followup that I started prior to you message.] Woah! Is this part of a concerted effort to eliminate support for modern platforms? Is that why LP64 64-bit compatibility is so broken and the Zend engine and PHP modules are drifting away from C-code portability? Is this part due to a move by Zend to only support commercially-associated hardware or something? Some missing details here. I'm not sure what status to believe this bug is at. I think "Open". It's been changed to "Bogus" twice but from what you've said, it sounds like "Won't Fix" (I don't have that option in the bug tracking interface, perhaps you do?). Of 147 packages that I compile on the same architecture, and who-knows-how-many-more that come in packages, why is PHP avoiding support? Won't it be detrimental if operating system vendors have to heavily patch/port PHP in order to keep it working on their platforms (in order to maintain viability of those platforms)? Is there an arbitration board or core developer group that I can speak to about this? Sounds like an off-list matter to begin with. Previous Comments: [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe and ask them to change their software because PHP has shown us how it should be done. > What is left could be the fact that you used "libpng12" and > i am not quite sure if we want to search for all versions since there > should be links named libpng. whatever that point to the specific > version (thats different from db-n where we search for a specific > version). libpng chooses libpng12 (as described in its docs). But I do seem to have symlinks using the name libpng rather than libpng12, as you say. Sorry for the confusion! My fault for not being particularly familiar with libpng. Anyway, in my eyes my original bug report stands, including my comment that other configuration steps, such as for LDAP, are broken. Hmm, looking at some live pages right now, LDAP compiled in fine with PHP 4.3.0 pre-release CVS. Although I had to patch PHP extensively to make it install, load, and work correctly, I don't remember having to patch anything in the configure script. Then again, my memory does have many faults. ...pause to wait for fresh copies of PHP to run 'configure'... Yes, 4.3.0 release seems to report an error when trying to find ldap whereas 4.3.0 CVS (unknown date, I could find out though) seems fine. I may have to leave this matter overnight since it is 7pm in my timezone. (Which is extremely different to whatever timezone -- apparently not UTC -- that the bugs.php.net interface seems to use :) [2003-01-31 04:18:23] [EMAIL PROTECTED] The way this works, works for 99.99% of users. We're not going to change this. [2003-01-31 04:08:00] [EMAIL PROTECTED] 1) The patch allows to present the correct error message without changing anything else yet. I am working on a php wide patch that solves such problems generically. 2) I knew before what you are trying to. However you got a
#21973 [Bgs->Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe and ask them to change their software because PHP has shown us how it should be done. > What is left could be the fact that you used "libpng12" and > i am not quite sure if we want to search for all versions since there > should be links named libpng. whatever that point to the specific > version (thats different from db-n where we search for a specific > version). libpng chooses libpng12 (as described in its docs). But I do seem to have symlinks using the name libpng rather than libpng12, as you say. Sorry for the confusion! My fault for not being particularly familiar with libpng. Anyway, in my eyes my original bug report stands, including my comment that other configuration steps, such as for LDAP, are broken. Hmm, looking at some live pages right now, LDAP compiled in fine with PHP 4.3.0 pre-release CVS. Although I had to patch PHP extensively to make it install, load, and work correctly, I don't remember having to patch anything in the configure script. Then again, my memory does have many faults. ...pause to wait for fresh copies of PHP to run 'configure'... Yes, 4.3.0 release seems to report an error when trying to find ldap whereas 4.3.0 CVS (unknown date, I could find out though) seems fine. I may have to leave this matter overnight since it is 7pm in my timezone. (Which is extremely different to whatever timezone -- apparently not UTC -- that the bugs.php.net interface seems to use :) Previous Comments: [2003-01-31 04:18:23] [EMAIL PROTECTED] The way this works, works for 99.99% of users. We're not going to change this. [2003-01-31 04:08:00] [EMAIL PROTECTED] 1) The patch allows to present the correct error message without changing anything else yet. I am working on a php wide patch that solves such problems generically. 2) I knew before what you are trying to. However you got a problem simply because you wnated to save some bytes... Try this layout .../normal/png/lib .../normal/png/include .../sparcv9/png/lib .../sparcv9/png/include What is left could be the fact that you used "libpng12" and i am not quite sure if we want to search for all versions since there should be links named libpng.whatever that point to the specific version (thats different from db-n where we search for a specific version). If you use the layout above you even have no need to configure any compiler linker configuration before calling ./configure. [2003-01-31 03:34:09] [EMAIL PROTECTED] In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't und
#21977 [Com]: ./configure --with-interbase (or with --with-enable-all) broken
ID: 21977
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: InterBase related
Operating System: Gentoo/Linux
PHP Version: 4CVS-2003-01-31 (stable)
New Comment:
but when i enable something, then configure should also check if it
exists.
Previous Comments:
[2003-01-31 04:47:42] [EMAIL PROTECTED]
If you don't have something, use '--without-interbase' for example.
--enable-all is not really useful, it's just a side-effect
of adding --disable-all, which IS useful.
This _IS_NOT_BUG_. Please stop submitting bug reports about
this already..
[2003-01-31 04:40:19] [EMAIL PROTECTED]
I don't have interbase on my machine.
./configure --with-interbase |grep -i interbase
checking for InterBase support... yes
from config.log:
configure:46431: gcc -o conftest -g -O2 -Wl,-rpath,/usr/interbase/lib
-L/usr/interbase/lib conftest.c -lgds -lcrypt -lresolv -lm -ldl -lnsl
-lcrypt 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 46420 "configure"
#include "confdefs.h"
#include
int main()
{
FILE *f=fopen("conftestval", "w");
if (!f) return(1);
fprintf(f, "%d\n", sizeof(char));
return(0);
}
libgds is interbase library...
when running --with-enable-all
it brakes also ming support (config.log):
configure:43734: checking for Ming_useSWFVersion in -lming
configure:43753: gcc -o conftest -g -O2
-L/usr/lib
-Wl,-rpath,/usr/interbase/lib -L/usr/interbase/lib
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386 conftest.c -lming -lm
-lmhash -ljava -lgds -lcrypt -lpam -lgmp -lpng -lz -lz -lbz2 -lz
-lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 43742 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a
gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion();
int main() {
Ming_useSWFVersion()
; return 0; }
--
Edit this bug report at http://bugs.php.net/?id=21977&edit=1
#21977 [Opn->Bgs]: ./configure --with-interbase (or with --with-enable-all) broken
ID: 21977
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: InterBase related
Operating System: Gentoo/Linux
PHP Version: 4CVS-2003-01-31 (stable)
New Comment:
If you don't have something, use '--without-interbase' for example.
--enable-all is not really useful, it's just a side-effect
of adding --disable-all, which IS useful.
This _IS_NOT_BUG_. Please stop submitting bug reports about
this already..
Previous Comments:
[2003-01-31 04:40:19] [EMAIL PROTECTED]
I don't have interbase on my machine.
./configure --with-interbase |grep -i interbase
checking for InterBase support... yes
from config.log:
configure:46431: gcc -o conftest -g -O2 -Wl,-rpath,/usr/interbase/lib
-L/usr/interbase/lib conftest.c -lgds -lcrypt -lresolv -lm -ldl -lnsl
-lcrypt 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 46420 "configure"
#include "confdefs.h"
#include
int main()
{
FILE *f=fopen("conftestval", "w");
if (!f) return(1);
fprintf(f, "%d\n", sizeof(char));
return(0);
}
libgds is interbase library...
when running --with-enable-all
it brakes also ming support (config.log):
configure:43734: checking for Ming_useSWFVersion in -lming
configure:43753: gcc -o conftest -g -O2
-L/usr/lib
-Wl,-rpath,/usr/interbase/lib -L/usr/interbase/lib
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386 conftest.c -lming -lm
-lmhash -ljava -lgds -lcrypt -lpam -lgmp -lpng -lz -lz -lbz2 -lz
-lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 43742 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a
gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion();
int main() {
Ming_useSWFVersion()
; return 0; }
--
Edit this bug report at http://bugs.php.net/?id=21977&edit=1
#21977 [NEW]: ./configure --with-interbase (or with --with-enable-all) broken
From: [EMAIL PROTECTED]
Operating system: Gentoo/Linux
PHP version: 4CVS-2003-01-31 (stable)
PHP Bug Type: InterBase related
Bug description: ./configure --with-interbase (or with --with-enable-all) broken
I don't have interbase on my machine.
./configure --with-interbase |grep -i interbase
checking for InterBase support... yes
from config.log:
configure:46431: gcc -o conftest -g -O2 -Wl,-rpath,/usr/interbase/lib
-L/usr/interbase/lib conftest.c -lgds -lcrypt -lresolv -lm -ldl -lnsl
-lcrypt 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 46420 "configure"
#include "confdefs.h"
#include
int main()
{
FILE *f=fopen("conftestval", "w");
if (!f) return(1);
fprintf(f, "%d\n", sizeof(char));
return(0);
}
libgds is interbase library...
when running --with-enable-all
it brakes also ming support (config.log):
configure:43734: checking for Ming_useSWFVersion in -lming
configure:43753: gcc -o conftest -g -O2
-L/usr/lib
-Wl,-rpath,/usr/interbase/lib -L/usr/interbase/lib
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/server
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386/native_threads
-Wl,-rpath,/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386
-L/opt/blackdown-jdk-1.4.1_beta/jre/lib/i386 conftest.c -lming -lm
-lmhash -ljava -lgds -lcrypt -lpam -lgmp -lpng -lz -lz -lbz2 -lz -lcrypt
-lresolv -lm -ldl -lnsl -lcrypt -lxml2 -lz -lm 1>&5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgds
collect2: ld returned 1 exit status
configure: failed program was:
#line 43742 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char Ming_useSWFVersion();
int main() {
Ming_useSWFVersion()
; return 0; }
--
Edit bug report at http://bugs.php.net/?id=21977&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21977&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21977&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21977&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21977&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21977&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21977&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21977&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21977&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21977&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21977&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21977&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21977&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21977&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21977&r=gnused
#21953 [Opn->Fbk]: $_session looses type
ID: 21953 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: linux PHP Version: 4.3.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2003-01-29 15:34:37] [EMAIL PROTECTED] The following snippet: $bunch=10; $_SESSION['mail'] = (int)$_SESSION['mail'] + $bunch; only works with the (int) in front of $_session. Otherwise get "unsupported operand types" error. This is mysterious, Session control in PHP should preserve type. Typical Session file was as follows: mail|i:-1;Mail_title|s:4:"test";Mail_body|s:4:"test"; you see mail was of type i. -- Edit this bug report at http://bugs.php.net/?id=21953&edit=1
#16548 [Opn->Fbk]: exec or system a daemon will catch the port for this session
ID: 16548 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: RED HAT Linux 7.2 PHP Version: 4.1.2 & 4.3.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-01-30 09:13:28] [EMAIL PROTECTED] Re-opened. I this has been happening to us, as well (php4.2.2 / CGI (command line) / RH7.3 x86). We are unable to reproduce this reliable, but our error trap is showing many "unable to fork" errors on exec calls. S [2003-01-16 11:20:37] [EMAIL PROTECTED] I have a similar problem here : Apache 1.3.27, PHP 4.3.0 . It happens when i restart dhcpd via a setuid script launched using exec() inside PHP. Everything looks normal : tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6024/httpd But if i kill httpd : tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6457/dhcpd Tried launching the script with system() , exec(), putting nohup and & in the end... nothing works. I have to kill dhcpd before i have a chance to start httpd again... [2002-12-25 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-07 01:54:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-29 11:04:07] [EMAIL PROTECTED] this bug does not relate to session module. 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/16548 -- Edit this bug report at http://bugs.php.net/?id=16548&edit=1
#21976 [Bgs]: ./configure --with-all doesn't include --with-imap-ssl
ID: 21976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Compile Issues Operating System: Linux/Gentoo PHP Version: 4CVS-2003-01-31 (stable) New Comment: --with-all I meant.. Previous Comments: [2003-01-31 04:20:21] [EMAIL PROTECTED] There is not 'wiht-all' option. Bogus. [2003-01-31 04:01:43] [EMAIL PROTECTED] when running ./configure --with-all then it should also include --with-imap-ssl This happens only, when c-client has been compiled with ssl. -- Edit this bug report at http://bugs.php.net/?id=21976&edit=1
#21976 [Opn->Bgs]: ./configure --with-all doesn't include --with-imap-ssl
ID: 21976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: Linux/Gentoo PHP Version: 4CVS-2003-01-31 (stable) New Comment: There is not 'wiht-all' option. Bogus. Previous Comments: [2003-01-31 04:01:43] [EMAIL PROTECTED] when running ./configure --with-all then it should also include --with-imap-ssl This happens only, when c-client has been compiled with ssl. -- Edit this bug report at http://bugs.php.net/?id=21976&edit=1
#21973 [Opn->Bgs]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: The way this works, works for 99.99% of users. We're not going to change this. Previous Comments: [2003-01-31 04:08:00] [EMAIL PROTECTED] 1) The patch allows to present the correct error message without changing anything else yet. I am working on a php wide patch that solves such problems generically. 2) I knew before what you are trying to. However you got a problem simply because you wnated to save some bytes... Try this layout .../normal/png/lib .../normal/png/include .../sparcv9/png/lib .../sparcv9/png/include What is left could be the fact that you used "libpng12" and i am not quite sure if we want to search for all versions since there should be links named libpng.whatever that point to the specific version (thats different from db-n where we search for a specific version). If you use the layout above you even have no need to configure any compiler linker configuration before calling ./configure. [2003-01-31 03:34:09] [EMAIL PROTECTED] In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and loader. [2003-01-31 03:14:27] [EMAIL PROTECTED] 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. 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/21973 -- Edit this bug report at http://bugs.php.net/
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: 1) The patch allows to present the correct error message without changing anything else yet. I am working on a php wide patch that solves such problems generically. 2) I knew before what you are trying to. However you got a problem simply because you wnated to save some bytes... Try this layout .../normal/png/lib .../normal/png/include .../sparcv9/png/lib .../sparcv9/png/include What is left could be the fact that you used "libpng12" and i am not quite sure if we want to search for all versions since there should be links named libpng.whatever that point to the specific version (thats different from db-n where we search for a specific version). If you use the layout above you even have no need to configure any compiler linker configuration before calling ./configure. Previous Comments: [2003-01-31 03:34:09] [EMAIL PROTECTED] In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and loader. [2003-01-31 03:14:27] [EMAIL PROTECTED] 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. 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/21973 -- Edit this bu
#21976 [NEW]: ./configure --with-all doesn't include --with-imap-ssl
From: [EMAIL PROTECTED] Operating system: Linux/Gentoo PHP version: 4CVS-2003-01-31 (stable) PHP Bug Type: *Compile Issues Bug description: ./configure --with-all doesn't include --with-imap-ssl when running ./configure --with-all then it should also include --with-imap-ssl This happens only, when c-client has been compiled with ssl. -- Edit bug report at http://bugs.php.net/?id=21976&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21976&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21976&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21976&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21976&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21976&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21976&r=support Expected behavior: http://bugs.php.net/fix.php?id=21976&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21976&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21976&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21976&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21976&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21976&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21976&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21976&r=gnused
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and loader. Previous Comments: [2003-01-31 03:14:27] [EMAIL PROTECTED] 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Int
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Compile Failure +Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. Previous Comments: [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib I
#21973 [Bgs->Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. Previous Comments: [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib In a mixed processor mode environment where there can be multiple architecture variants of libraries (e.g. one that uses the processor's preferred arch and one that uses a compatibility arch), something has to give. In Sun's case, it decided on the convention of putting different architectures into different directories, preventing files from one arch obliterating files from another. And in the end, I got PHP 4.3.0 to compile but it still thinks sizeof(int) == sizeof(long) and crashes during installation. [2003-01-30 19:35:26] [EMAIL PROTECTED] You make it sound like a 'why does php do this' type of problem, but think about it: if > 90% of unices put libraries in $prefix/lib, then you can just see the Sun people sitting in their offices saying: "let's make portable software sweat a little so everybody uses Solaris again". Working towards the solution: is there a config script, like png-config, which reports how the library was installed - s
#21751 [Asn]: make test miserably fails
ID: 21751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Output Control Operating System: SunOS PHP Version: 4.3.0 Assigned To: helly New Comment: The part already closed (the eb_end_clean() loop) was also reported in http://bugs.php.net/21647 Previous Comments: [2003-01-25 13:55:49] [EMAIL PROTECTED] Symptoms are defeated the real problem remains: "failed to delete buffer default output handler" In other words with cvs versions you can do now: php -d output_buffering=4096 run-tests.php Interesting thing is that it worked in 4.2 [2003-01-19 10:45:00] [EMAIL PROTECTED] I didn't have "." in my include_path and I had output_buffering = 4096. Reasonable? So the while(ob_get_level()) ob_end_clean(); algorithm in run-tsts.php runs forever: level won't go below 1. An implicit ob_start implied by buffering? then the feature is fine and the test script broken. I commented that out but forgot to fix the .ini. Result: many test failures and the result posted to your site w/o letting me say a word. (Quite nasty, isn't it?) In facts: 1) "-n" or "-c ." options to command line don't do it, 2) flush() doesn't work as expected when bufferning, 3) reading stdin doesn't work at all! You need to fix (1) and ship the product with a working php.ini for the tests. Please fix the tests by setting something like "do you want to run the tests interactively?" and if you get no answer assume NO_INTERACTION=1! TIA Ale -- Edit this bug report at http://bugs.php.net/?id=21751&edit=1
#21647 [NoF->Csd]: make test gives loop error
ID: 21647 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: *General Issues Operating System: solaris 8 PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Also see http://bugs.php.net/21751 for more info. However this part is fixed. Previous Comments: [2003-01-31 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2003-01-15 03:27:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-14 23:50:11] [EMAIL PROTECTED] SED is gnu also [2003-01-14 23:49:10] [EMAIL PROTECTED] gcc 3.2.1 with gnu ld and solaris 8 with latest patches apache 2.0.43 and php 4.3.0 compile with --with-apxs2=/PATH_TO_APXS or anything and I get this loop are after make make test and this is what I get ( I am not running php in safe mode) PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php ?? added question marks -- Edit this bug report at http://bugs.php.net/?id=21647&edit=1
#21973 [Opn->Bgs]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. Previous Comments: [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib In a mixed processor mode environment where there can be multiple architecture variants of libraries (e.g. one that uses the processor's preferred arch and one that uses a compatibility arch), something has to give. In Sun's case, it decided on the convention of putting different architectures into different directories, preventing files from one arch obliterating files from another. And in the end, I got PHP 4.3.0 to compile but it still thinks sizeof(int) == sizeof(long) and crashes during installation. [2003-01-30 19:35:26] [EMAIL PROTECTED] You make it sound like a 'why does php do this' type of problem, but think about it: if > 90% of unices put libraries in $prefix/lib, then you can just see the Sun people sitting in their offices saying: "let's make portable software sweat a little so everybody uses Solaris again". Working towards the solution: is there a config script, like png-config, which reports how the library was installed - similar to mysql_config/curl-config/mm-config and such? If not - does this apply to all Solaris 8 installed libraries and also to headers or is this different for different packages? [2003-01-30 18:42:42] [EMAIL PROTECTED] ./configure from the 4.3.0 release contains constructs like: for i in /usr /usr/local $PHP_PNG_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f \ $i/lib/libpng.a && GD_PNG_DIR=$i done The 'lib/libpng.' bit is hard-coded. But my libpng is at /usr/local/lib/sparcv9/libpng.so The end of configure's output is: checking for the
