Req #43177 [Com]: Errors in eval()'ed code produce status code 500
Edit report at https://bugs.php.net/bug.php?id=43177edit=1
ID: 43177
Comment by: truth at proposaltech dot com
Reported by:taneli at crasman dot fi
Summary:Errors in eval()'ed code produce status code 500
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
It's been over 4 years and the fix is known! I can't believe I spent all day
yesterday debugging this. I was filing a bug report and the system found this
match. I'm using php 5.4.3. I'll paste the rest of my notes into this comment
because they include references to the documentation, updated line numbers, and
other details not present in the original report. Please commit a fix! More
and more people will hit this as more and more people use AJAX.
--- Description: ---
http://us2.php.net/manual/en/function.eval.php states:
If there is a parse error in the evaluated code, eval() returns FALSE and
execution of the following code continues normally.
In reality, eval() can have the side effect of setting the response code to 500
and leaving it at 500. My guess is that this has gone unnoticed because
everything else proceeds normally enough to produce an otherwise normal page
and browsers are willing to display such pages even though the response code is
500. However, wget complains about the 500 and an AJAX framework that checks
response codes may refuse to display the page. I believe the point of
continuing normally is that eval() should not ruin the current page.
I think the fix is to put
EG(current_execute_data)-opline-extended_value != ZEND_EVAL
into the if block at line 1132 of main.c. The if decides whether to set
the response code to 500 in the case of a parse error.
I just noticed the exit status is also modified by eval() a few lines earlier.
Given the function description, it doesn't seem correct to force the exit
status to 255. I guess the same if applies.
I'm guessing it is redundant to make sure the type is E_PARSE in the the case
of ZEND_EVAL, but someone how knows more about internals should probably
confirm that.
--- Test script: ---
?php
eval('0+');
print hello world\n;
?
--- Expected result: ---
hello world
with exit code 0
--- Actual result ---
That looks good in a browser, but fails with wget (and my AJAX framework and
anything else that relies on the response code). On the command line, the exit
code is 255.
Previous Comments:
[2007-11-05 11:06:51] holster at iki dot fi
A vote from me. Parse error in eval'ed code should not alter HTTP status
(well, as long as one is not able to catch it).
[2007-11-02 11:43:10] taneli at crasman dot fi
Here's a patch for this issue:
--- php-5.2.4-vanilla/main/main.c 2007-11-01 15:20:37.0 +0200
+++ php-5.2.4/main/main.c 2007-11-01 17:26:45.0 +0200
@@ -957,11 +957,15 @@
if (!SG(headers_sent)
SG(sapi_headers).http_response_code ==
200
) {
- sapi_header_line ctr = {0};
-
- ctr.line = HTTP/1.0 500 Internal
Server Error;
- ctr.line_len = strlen(ctr.line);
- sapi_header_op(SAPI_HEADER_REPLACE,
ctr TSRMLS_CC);
+ if (!EG(current_execute_data) ||
+
!EG(current_execute_data)-opline ||
+
EG(current_execute_data)-opline-opcode != ZEND_INCLUDE_OR_EVAL) {
+ sapi_header_line ctr = {0};
+
+ ctr.line = HTTP/1.0 500
Internal Server Error;
+ ctr.line_len = strlen(ctr.line);
+
sapi_header_op(SAPI_HEADER_REPLACE, ctr TSRMLS_CC);
+ }
}
/* the parser would return 1 (failure), we can
bail out nicely */
if (type != E_PARSE) {
[2007-11-02 11:41:44] taneli at crasman dot fi
Description:
Errors in eval()'ed code produces HTTP status code 500 for the request.
Reproduce code:
---
Script:
?php {
eval(this is not right);
}?
Result:
# curl -I http://localhost/test.php
HTTP/1.0 500 Internal Server Error
Expected result:
Since parse errors and such in eval()'ed code don't interrupt
Req #43177 [Com]: Errors in eval()'ed code produce status code 500
Edit report at https://bugs.php.net/bug.php?id=43177edit=1
ID: 43177
Comment by: truth at proposaltech dot com
Reported by:taneli at crasman dot fi
Summary:Errors in eval()'ed code produce status code 500
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
A fix is available in
https://github.com/jabouillei/php-src/tree/issue-43177
The changes are in main.c and zend.c. github shows other files as being
modified also, but that's probably from me not understanding part of the merge
process. My changes are in commit a65037ef46.
Previous Comments:
[2012-06-01 17:40:36] truth at proposaltech dot com
It's been over 4 years and the fix is known! I can't believe I spent all day
yesterday debugging this. I was filing a bug report and the system found this
match. I'm using php 5.4.3. I'll paste the rest of my notes into this comment
because they include references to the documentation, updated line numbers, and
other details not present in the original report. Please commit a fix! More
and more people will hit this as more and more people use AJAX.
--- Description: ---
http://us2.php.net/manual/en/function.eval.php states:
If there is a parse error in the evaluated code, eval() returns FALSE and
execution of the following code continues normally.
In reality, eval() can have the side effect of setting the response code to 500
and leaving it at 500. My guess is that this has gone unnoticed because
everything else proceeds normally enough to produce an otherwise normal page
and browsers are willing to display such pages even though the response code is
500. However, wget complains about the 500 and an AJAX framework that checks
response codes may refuse to display the page. I believe the point of
continuing normally is that eval() should not ruin the current page.
I think the fix is to put
EG(current_execute_data)-opline-extended_value != ZEND_EVAL
into the if block at line 1132 of main.c. The if decides whether to set
the response code to 500 in the case of a parse error.
I just noticed the exit status is also modified by eval() a few lines earlier.
Given the function description, it doesn't seem correct to force the exit
status to 255. I guess the same if applies.
I'm guessing it is redundant to make sure the type is E_PARSE in the the case
of ZEND_EVAL, but someone how knows more about internals should probably
confirm that.
--- Test script: ---
?php
eval('0+');
print hello world\n;
?
--- Expected result: ---
hello world
with exit code 0
--- Actual result ---
That looks good in a browser, but fails with wget (and my AJAX framework and
anything else that relies on the response code). On the command line, the exit
code is 255.
[2007-11-05 11:06:51] holster at iki dot fi
A vote from me. Parse error in eval'ed code should not alter HTTP status
(well, as long as one is not able to catch it).
[2007-11-02 11:43:10] taneli at crasman dot fi
Here's a patch for this issue:
--- php-5.2.4-vanilla/main/main.c 2007-11-01 15:20:37.0 +0200
+++ php-5.2.4/main/main.c 2007-11-01 17:26:45.0 +0200
@@ -957,11 +957,15 @@
if (!SG(headers_sent)
SG(sapi_headers).http_response_code ==
200
) {
- sapi_header_line ctr = {0};
-
- ctr.line = HTTP/1.0 500 Internal
Server Error;
- ctr.line_len = strlen(ctr.line);
- sapi_header_op(SAPI_HEADER_REPLACE,
ctr TSRMLS_CC);
+ if (!EG(current_execute_data) ||
+
!EG(current_execute_data)-opline ||
+
EG(current_execute_data)-opline-opcode != ZEND_INCLUDE_OR_EVAL) {
+ sapi_header_line ctr = {0};
+
+ ctr.line = HTTP/1.0 500
Internal Server Error;
+ ctr.line_len = strlen(ctr.line);
+
sapi_header_op(SAPI_HEADER_REPLACE, ctr TSRMLS_CC);
+ }
}
/* the parser would return 1 (failure), we can
bail out nicely */
if (type != E_PARSE
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129edit=1
ID: 62129
Comment by: truth at proposaltech dot com
Reported by:truth at proposaltech dot com
Summary:rfc1867 crashes php even though turned off
Status: Assigned
Type: Bug
Package:Session related
Operating System: CentOS
PHP Version:5.4.3
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
Here is a the relevant portion of the backtrace from the seg fault:
#104648 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104649 0x006cd5b8 in php_session_rfc1867_callback (event=0,
event_data=0x7fffb2b8f950, extra=value optimized out)
at /cns/build/php-5.4.3/ext/session/session.c:2388
#104650 0x00473841 in rfc1867_post_handler (
content_type_dup=value optimized out, arg=0x11535e8)
at /cns/build/php-5.4.3/main/rfc1867.c:773
#104651 0x00471372 in sapi_handle_post (arg=value optimized out)
at /cns/build/php-5.4.3/main/SAPI.c:182
#104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0,
destArray=value optimized out)
at /cns/build/php-5.4.3/ext/mbstring/mb_gpc.c:98
#104653 0x00475e9e in php_auto_globals_create_post (
name=0x12a6a60 _POST, name_len=5)
at /cns/build/php-5.4.3/main/php_variables.c:682
#104654 0x0049aa4b in zend_auto_global_init (auto_global=0x110e800)
at /cns/build/php-5.4.3/Zend/zend_compile.c:
#104655 0x004ca974 in zend_hash_apply (ht=0x111bf20,
apply_func=0x49aa30 zend_auto_global_init)
at /cns/build/php-5.4.3/Zend/zend_hash.c:716
#104656 0x004772bb in php_hash_environment ()
at /cns/build/php-5.4.3/main/php_variables.c:642
#104657 0x004697f5 in php_request_startup ()
at /cns/build/php-5.4.3/main/main.c:1568
#104658 0x0056084f in apache_php_module_main (r=value optimized out,
display_source_mode=0) at /cns/build/php-5.4.3/sapi/apache/sapi_apache.c:33
#104659 0x00461c00 in send_php ()
#104660 0x00461c48 in send_parsed_php ()
#104661 0x0085f773 in ap_invoke_handler ()
#104662 0x00878d90 in process_request_internal ()
#104663 0x00878df3 in ap_process_request ()
#104664 0x0086e46f in child_main ()
#104665 0x0086e728 in make_child ()
#104666 0x0086e7e9 in startup_children ()
#104667 0x0086effb in standalone_main ()
#104668 0x0086f8cc in main ()
I don't know much about internals, but I'll try to translate the
above based on function names and values I saw in the debugger.
While activating auto_globals, the _POST auto_global had a
callback to be called: php_auto_globals_create_post().
That used the mbstring extension, which for the case of
PARSE_POST, relies on sapi_handle_post().
sapi_handle_post() used rfc1867_post_handler()
because the sapi_globals.request_info.post_entry had
an rfc1867 post_handler:
print *sapi_globals.request_info.post_entry
$7 = {content_type = 0x8c4bc9 multipart/form-data, content_type_len = 19,
post_reader = 0, post_handler = 0x473590 rfc1867_post_handler}
I don't know why that post_handler value was set to
rfc1867_post_handler given that my php.ini includes
session.upload_progress.enabled = off
Similarly, I don't know why php_rfc1867_callback was
non-null given my php.ini setting.
Once the php_rfc1867_callback() was called, everything
died quickly. That callback calls the orig_callback
(if non-null) and the orig_callback was the same as
the php_session_rfc1867_callback - endless recursion.
Perhaps the real killer is the following lines from
session.c (~line 2195):
php_session_rfc1867_orig_callback = php_rfc1867_callback;
php_rfc1867_callback = php_session_rfc1867_callback;
I don't think those lines should be called if I have
session.upload_progress.enabled = off
in my php.ini. Setting php_rfc1867_callback seems
to be what cause rfc1867 code to be called. Setting
php_session_rfc1867_orig_callback to php_rfc1867_callback
(which is php_session_rfc1867_callback) leads to the
endless recursion.
Sorry I don't have a fix.
Thanks very much for continuing to improve php!!!
Previous Comments:
[2012-05-24 01:45:19] larue...@php.net
yes, the codes seems suspicious, maybe iliaa can look into this :)
diff --git a/ext/session/session.c b/ext/session/session.c
index 7a8199d..851e4ea 100644
--- a/ext/session/session.c
+++ b/ext/session/session.c
@@ -2384,13 +2384,14 @@ static int php_session_rfc1867_callback(unsigned int
event, void *event_data, vo
php_session_rfc1867_progress *progress;
int retval = SUCCESS;
- if (php_session_rfc1867_orig_callback) {
- retval = php_session_rfc1867_orig_callback(event, event_data
[PHP-BUG] Bug #62129 [NEW]: rfc1867 crashes php even though turned off
From: truth at proposaltech dot com Operating system: CentOS PHP version: 5.4.3 Package: Session related Bug Type: Bug Bug description:rfc1867 crashes php even though turned off Description: php_session_rfc1867_callback() tries to call php_session_rfc1867_orig_callback() even if the rfc1867 feature is not enabled. Switching the order of the opening if blocks fixes the problem. (The second if block immediately returns success if the feature isn't enabled and the first if block tries to call the callback. This is all around line 2388 of session.c.) I upgraded from 5.3.3 to 5.4.3 and apache was segfaulting. I produced a core and the debugger showed infinite recursion in php_session_rfc1867_callback(). There are probably deeper problems here, but at the least the feature shouldn't cause problems if it is turned off. In any case, even if something about my configuration is less than ideal, seg faults are Bad Thing. Test script: --- Apparently, my code wasn't executed. I tried using Xdebug, but it didn't report anything. dump_bt didn't return anything in the debugger. Expected result: I expected my code to be executed normally. Actual result: -- apache seg faulted -- Edit bug report at https://bugs.php.net/bug.php?id=62129edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62129r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62129r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62129r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62129r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62129r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62129r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62129r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62129r=needscript Try newer version: https://bugs.php.net/fix.php?id=62129r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62129r=support Expected behavior: https://bugs.php.net/fix.php?id=62129r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62129r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62129r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62129r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62129r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62129r=dst IIS Stability: https://bugs.php.net/fix.php?id=62129r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62129r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62129r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62129r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62129r=mysqlcfg
#34551 [NEW]: Unadvertised BC break
From: truth at proposaltech dot com
Operating system: SuSE w/ rebuilt php deps
PHP version: 4.4.0
PHP Bug Type: Scripting Engine problem
Bug description: Unadvertised BC break
Description:
Based on the discussion on internals that led to the
creation of php 4.4 (and based on the release notes
for php 4.4), I would expect the only difference in
running the following code under 4.3 and 4.4 to be the
generation of a notice under 4.4. The code is bad,
but it does not rely on corrupting memory.
(BTW, this actually doesn't affect me personally because
I immediately cleaned up our company's code for every
4.4 notice. I'm just helping isolate the BC break
that frustrated a recent internals poster. Unless
they are relying on memory corruption, users should be
able to hide the notices and get the same behavior
with 4.4 as 4.3. (There were posts from Zeev among
others supporting this position.))
I hope this is easy to fix. The concept is easy.
Whenever the code attempts to set a variable by
reference, the variable should be unset as a first
step. In the example, $y should be disconnected
from $x because of the $y = Yes, the reference
shouldn't actually work, but that doesn't change the
fact that the code clearly indicates that the connection
between $y and $x should be broken. If I sound
defensive, it's because Derick has already posted on
internals that the new behavior is correct. Please
check with other engine gurus before jumping to any
conclusions of bogusness. I think a fix to this BC
break will save many hours for many, many php
developers. (The example is silly, but you
can get subtle cases of that problem in loops that
are a nightmare to find.)
Thanks!
- Todd
Reproduce code:
---
?php
function f() { return 3; }
$x = 5;
$y = $x;
$y = f();
var_dump($x);
?
Expected result:
$x should end up 5 because the $y=... should disconnect
$y from $x even though the new connection can't be made.
Actual result:
--
Under 4.3, $x ends up 5, but under 4.4, $x ends up 3.
--
Edit bug report at http://bugs.php.net/?id=34551edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34551r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34551r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34551r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34551r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34551r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34551r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34551r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34551r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34551r=support
Expected behavior: http://bugs.php.net/fix.php?id=34551r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34551r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34551r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34551r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34551r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34551r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34551r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34551r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34551r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34551r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34551r=mysqlcfg
#34551 [Bgs]: Unadvertised BC break
ID: 34551
User updated by: truth at proposaltech dot com
Reported By: truth at proposaltech dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: SuSE w/ rebuilt php deps
PHP Version: 4.4.0
New Comment:
According to http://www.php.net/release_4_4_0.php...
It states, The increased middle digit was required because the fix
that corrected the problem with references changed PHP's internal API,
breaking binary compatibility with the PHP 4.3.* series. Please note
the middle digit change regarded an _internal_ API, not an API visible
to the user.
It also states, ... will now throw an E_NOTICE when references are
incorrectly used in the script. This is intended to alert developers to
minor errors in their approach, and does not affect the script's
performance in any other way. Not disconnecting a variable from
previous reference assignments when using an = does indeed affect a
script's performance in a way beyond throwing notices.
Previous Comments:
[2005-09-19 18:29:44] [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
Release announcement is pretty clear about this, this is why the
release is 4.4.0 and not 4.3.12
[2005-09-19 18:15:03] truth at proposaltech dot com
Description:
Based on the discussion on internals that led to the
creation of php 4.4 (and based on the release notes
for php 4.4), I would expect the only difference in
running the following code under 4.3 and 4.4 to be the
generation of a notice under 4.4. The code is bad,
but it does not rely on corrupting memory.
(BTW, this actually doesn't affect me personally because
I immediately cleaned up our company's code for every
4.4 notice. I'm just helping isolate the BC break
that frustrated a recent internals poster. Unless
they are relying on memory corruption, users should be
able to hide the notices and get the same behavior
with 4.4 as 4.3. (There were posts from Zeev among
others supporting this position.))
I hope this is easy to fix. The concept is easy.
Whenever the code attempts to set a variable by
reference, the variable should be unset as a first
step. In the example, $y should be disconnected
from $x because of the $y = Yes, the reference
shouldn't actually work, but that doesn't change the
fact that the code clearly indicates that the connection
between $y and $x should be broken. If I sound
defensive, it's because Derick has already posted on
internals that the new behavior is correct. Please
check with other engine gurus before jumping to any
conclusions of bogusness. I think a fix to this BC
break will save many hours for many, many php
developers. (The example is silly, but you
can get subtle cases of that problem in loops that
are a nightmare to find.)
Thanks!
- Todd
Reproduce code:
---
?php
function f() { return 3; }
$x = 5;
$y = $x;
$y = f();
var_dump($x);
?
Expected result:
$x should end up 5 because the $y=... should disconnect
$y from $x even though the new connection can't be made.
Actual result:
--
Under 4.3, $x ends up 5, but under 4.4, $x ends up 3.
--
Edit this bug report at http://bugs.php.net/?id=34551edit=1
#22860 [NEW]: odbc_longreadlen() corruption problem
From: truth at ichaos dot com Operating system: SuSE 8.0 PHP version: 4.3.0 PHP Bug Type: ODBC related Bug description: odbc_longreadlen() corruption problem When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit bug report at http://bugs.php.net/?id=22860edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22860r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22860r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22860r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22860r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22860r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22860r=support Expected behavior: http://bugs.php.net/fix.php?id=22860r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22860r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22860r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22860r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22860r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22860r=dst IIS Stability: http://bugs.php.net/fix.php?id=22860r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22860r=gnused
#22860 [Fbk-Opn]: odbc_longreadlen() corruption problem
ID: 22860 User updated by: truth at ichaos dot com Reported By: truth at ichaos dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 -PHP Version: 4.3.0 +PHP Version: 4.3.2-RC New Comment: All right, this snapshot didn't work. It's hard to write a script but here is a good try: First, a table in my IBM DB2 is created CREATE TABLE test ( ID INT, DATA CLOB(1M)); Put a string in the CLOB that is greater than 5K, and and ID = 1 or so. All right, now the script ? $linkid = odbc_connect(DBNAME, USER, PASSWORD); $result = odbc_exec($linkid, SELECT data FROM test WHERE id = 1); odbc_longreadlen($result, 200); odbc_binmode($result, ODBC_BINMODE_PASSTHRU); $result = odbc_result($this-result, 1) echo strlen($result); ? This should return the length of your string. If the odbc.defaultlrl is set to 4096, the string is 200 chars long. If odbc.defaultlrl is set to 200, the string is the correct length. Previous Comments: [2003-03-24 23:20:19] [EMAIL PROTECTED] And can you provide a script sample, and sample schema for me to use in testing? [2003-03-24 17:31:15] [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-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860edit=1
#22860 [Opn]: odbc_longreadlen() corruption problem
ID: 22860 User updated by: truth at ichaos dot com Reported By: truth at ichaos dot com Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.3.2-RC New Comment: Actually I tried this with a string that was 28968 chars long, and this it was actually 16388 chars long instead of 200. The characters beyond 4096 were corrupted. Sorry for the exagerated numbers. Previous Comments: [2003-03-24 23:52:36] truth at ichaos dot com All right, this snapshot didn't work. It's hard to write a script but here is a good try: First, a table in my IBM DB2 is created CREATE TABLE test ( ID INT, DATA CLOB(1M)); Put a string in the CLOB that is greater than 5K, and and ID = 1 or so. All right, now the script ? $linkid = odbc_connect(DBNAME, USER, PASSWORD); $result = odbc_exec($linkid, SELECT data FROM test WHERE id = 1); odbc_longreadlen($result, 200); odbc_binmode($result, ODBC_BINMODE_PASSTHRU); $result = odbc_result($this-result, 1) echo strlen($result); ? This should return the length of your string. If the odbc.defaultlrl is set to 4096, the string is 200 chars long. If odbc.defaultlrl is set to 200, the string is the correct length. [2003-03-24 23:20:19] [EMAIL PROTECTED] And can you provide a script sample, and sample schema for me to use in testing? [2003-03-24 17:31:15] [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-03-24 15:01:56] truth at ichaos dot com When odbc.defaultlrl is set to 4096 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is padded at the end with garbage (prolly from memory). When the odbc.defaultlrl is set to 200 in the php.ini file, and I call odbc_longreadlen($result, 200); in my script, the data returned for that $result is not padded at the end with garbage, and is just fine. -- Edit this bug report at http://bugs.php.net/?id=22860edit=1
#22593 [NEW]: New feature
From: truth at ichaos dot com Operating system: SuSE 8.0 PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: New feature I would like to request a new feature. Is it possible to tie in agrep (ftp://ftp.cs.arizona.edu/agrep/) into a PHP function to give everyone the ability to do fuzzy grep searches for various things? I think that would be a great help for people, and would help me greatly in a future project. Tom -- Edit bug report at http://bugs.php.net/?id=22593edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22593r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22593r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22593r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22593r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22593r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22593r=support Expected behavior: http://bugs.php.net/fix.php?id=22593r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22593r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22593r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22593r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22593r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22593r=dst IIS Stability: http://bugs.php.net/fix.php?id=22593r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22593r=gnused
#20928 [Fbk-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH 7.2 PHP Version: 4.3.0 New Comment: I havn't been able to get it to work at all as a DSO as something conflicts with mod_ssl and apache crashes. Previous Comments: [2003-01-17 20:30:31] [EMAIL PROTECTED] One thing I forgot to ask: Does it work if you compile PHP as DSO ? (--with-apxs) And try this too: # rm config.cache # ./configure --with-ibm-db2=/home/db2inst1 --disable-all # make [2003-01-16 10:53:20] [EMAIL PROTECTED] This isn't an ODBC issue per say, but rather a compile issue. Moving this to the compile category. Also updating version. [2002-12-19 19:59:32] [EMAIL PROTECTED] The latest snapshot yields this error when compiling PHP: gcc -Isapi/cli/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/ -DPH P_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/r edhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-20 0212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/in clude -I/usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/x ml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr /src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/php_cli.c -o sapi/cli/php_cl i.o echo sapi/cli/php_cli.lo gcc -Isapi/cli/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/ -DPH P_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/r edhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-20 0212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/in clude -I/usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/x ml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr /src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/getopt.c -o sapi/cli/getopt. o echo sapi/cli/getopt.lo gcc -Imain/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main/ -DPHP_ATOM_I NC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/redhat/BU ILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-2002122000 30 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/include -I /usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/xml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c main/interna l_functions_cli.c -o main/internal_functions_cli.o echo main/internal_func tions_cli.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst 1/lib -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix /lib/esql -L/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/informix -R /usr /local/lib -R /usr/local/Informix/lib -R /usr/local/Informix/lib/esql -R /usr/sr c/redhat/BUILD/php4-STABLE-200212200030/ext/informix ext/zlib/zlib.lo ext/zlib/z lib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcm ath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/ libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/sr c/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcm ath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcm ath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug. lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext /bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/li bbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext /fdf/fdf.lo ext/imap/php_imap.lo ext/informix/ifx.lo ext/ldap/ldap.lo ext/mysql/ php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mys ql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my _static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/ mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/m y_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/ mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/erro rs.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/li bmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo
#20928 [Fbk-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RH 7.2 PHP Version: 4.3.0 New Comment: I noticed that you do /home/db2inst1/lib...All DB2 instance home directories have sqllib as a subdirectory which lib is located in. You will want to add that to configure so that if someone says --with-ibm-db2=/home/db2inst1, it knows that everything is under /home/db2inst1/sqllib (include dirs, lib dirs, etc.). Thats how it used to work anyway. It must have gotten changed at some point. Nope, I get the following after make: [root@voyager php4-STABLE-200212200030]# make gcc -I -Isapi/cgi/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-200212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/cgi_main.c -o sapi/cgi/cgi_main.o echo sapi/cgi/cgi_main.lo /usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/cgi_main.c: In function `main': /usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/cgi_main.c:1000: warning: passing arg 2 of `cfg_get_long' from incompatible pointer type gcc -I -Isapi/cgi/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-200212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cgi/getopt.c -o sapi/cgi/getopt.o echo sapi/cgi/getopt.lo gcc -Imain/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-200212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c main/internal_functions.c -o main/internal_functions.o echo main/internal_functions.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst1/lib ext/odbc/php_odbc.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/memory_streams.lo main/user_streams.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo
#19349 [Fbk-Opn]: odbc_longreadlen() does not work
ID: 19349 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.2.1 New Comment: Don't put this in a different state yet as I can't get the snapshot to compile until bug #20928 is fixed. Previous Comments: [2003-01-06 12:24:10] [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 As soon as the CVS commit happens I think I fixed this. Give it a try and let me know. [2002-11-16 12:06:34] [EMAIL PROTECTED] Script is pretty simple. It's hard to just cut and paste because I have everything spread out in a bunch of classes. $linkid = odbc_pconnect(database, username, password); $result = odbc_exec($linkid, SELECT SUBSTR(document, 1, 200) FROM documents WHERE doc_id = 1); odbc_longreadlen($result, 200); odbc_binmode($result, ODBC_BINMODE_PASSTHRU); $column = odbc_result($result, 1); // A short example of what I'm trying to do. // $column should be filled with up to 200 bytes of data. // By default, it's up to 4096 bytes of data, or whatever is // set in the php.ini file. [2002-11-16 01:13:36] [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-11-02 14:51:11] [EMAIL PROTECTED] can you please provide the full script sample for this? I think I do see what is wrong, but want to make sure. [2002-09-11 10:27:31] [EMAIL PROTECTED] I have a script that runs a select statement from a 10MB CLOB field (among others). I run the following : odbc_longreadlen($resultid, 300); Then I run: $document = odbc_result($resultid, 2); The problem is, $document ends up with 4096 bytes of data (the default, NOT 300). If I edit php.ini and set up odbc_lrl to 200 in there, then $document ends up with 2MBin it. It acts like the function odbc_longreadlen does not work at all. I don't know how much more information I can give other than odbc_longreadlen does not seem to do anything at all. 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/19349 -- Edit this bug report at http://bugs.php.net/?id=19349edit=1
#20928 [Fbk-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: The latest snapshot yields this error when compiling PHP: gcc -Isapi/cli/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/ -DPH P_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/r edhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-20 0212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/in clude -I/usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/x ml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr /src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/php_cli.c -o sapi/cli/php_cl i.o echo sapi/cli/php_cli.lo gcc -Isapi/cli/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/ -DPH P_ATOM_INC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/r edhat/BUILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-20 0212200030 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/in clude -I/usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/x ml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c /usr /src/redhat/BUILD/php4-STABLE-200212200030/sapi/cli/getopt.c -o sapi/cli/getopt. o echo sapi/cli/getopt.lo gcc -Imain/ -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/main/ -DPHP_ATOM_I NC -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/include -I/usr/src/redhat/BU ILD/php4-STABLE-200212200030/main -I/usr/src/redhat/BUILD/php4-STABLE-2002122000 30 -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/Zend -I/usr/local/include -I /usr/include/imap -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/xml/expat -I/usr/src/redhat/BUILD/php4-STABLE-200212200030/TSRM -g -O2 -c main/interna l_functions_cli.c -o main/internal_functions_cli.o echo main/internal_func tions_cli.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst 1/lib -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix /lib/esql -L/usr/src/redhat/BUILD/php4-STABLE-200212200030/ext/informix -R /usr /local/lib -R /usr/local/Informix/lib -R /usr/local/Informix/lib/esql -R /usr/sr c/redhat/BUILD/php4-STABLE-200212200030/ext/informix ext/zlib/zlib.lo ext/zlib/z lib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcm ath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/ libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/sr c/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcm ath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcm ath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug. lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext /bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/li bbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext /fdf/fdf.lo ext/imap/php_imap.lo ext/informix/ifx.lo ext/ldap/ldap.lo ext/mysql/ php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mys ql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my _static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/ mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/m y_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/ mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/erro rs.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/li bmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo e xt/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmys ql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ex t/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/ mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/ mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysq l/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my _compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql /libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/my sql/libmysql/strmov.lo
#20928 [Csd]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: Fixed in which snapshot release? Just tried 4.3.x-dev and it's still broken: === src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-STABL E-200212111430/main -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/Zend -I/usr /src/redhat/BUILD/php4-STABLE-200212111430/TSRM -I/usr/src/redhat/BUILD/php4-STA BLE-200212111430 -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/sapi/apache -I /usr/src/redhat/BUILD/php4-STABLE-200212111430/main -I/usr/src/redhat/BUILD/php4 -STABLE-200212111430/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/TSRM mod_php4.c mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/ usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/sr c/redhat/BUILD/php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules /php4 -L../../modules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/lo cal/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redh at/BUILD/php4-STABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr /local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/ redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/usr/local/lib - L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/ php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules/php4 -L../../m odules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/local/lib -L/usr/ local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-S TABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifas f -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber - lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) Previous Comments: [2002-12-11 02:42:30] [EMAIL PROTECTED] 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. [2002-12-11 01:22:06] [EMAIL PROTECTED] It got much further this time, but results are the same. Here is the paste of the last command and error: === src/modules/throttle === src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-200212110630/ext/informix
#20928 [Csd-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: This is still broken, I used the PHP4.3.x_dev snapshot. Previous Comments: [2002-12-11 10:45:28] [EMAIL PROTECTED] Fixed in which snapshot release? Just tried 4.3.x-dev and it's still broken: === src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-STABL E-200212111430/main -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/Zend -I/usr /src/redhat/BUILD/php4-STABLE-200212111430/TSRM -I/usr/src/redhat/BUILD/php4-STA BLE-200212111430 -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/sapi/apache -I /usr/src/redhat/BUILD/php4-STABLE-200212111430/main -I/usr/src/redhat/BUILD/php4 -STABLE-200212111430/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/TSRM mod_php4.c mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/ usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/sr c/redhat/BUILD/php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules /php4 -L../../modules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/lo cal/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redh at/BUILD/php4-STABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr /local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/ redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/usr/local/lib - L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/ php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules/php4 -L../../m odules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/local/lib -L/usr/ local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-S TABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifas f -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber - lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) [2002-12-11 02:42:30] [EMAIL PROTECTED] 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. [2002-12-11 01:22:06] [EMAIL PROTECTED] It got much further this time, but results are the same. Here is the paste of the last command and error: === src/modules/throttle === src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so
#20928 [NEW]: Static compile of PHP module with IBM DB2 doesn't work right with apache
From: [EMAIL PROTECTED] Operating system: RH 7.2 PHP version: 4.3.0RC2 PHP Bug Type: Compile Failure Bug description: Static compile of PHP module with IBM DB2 doesn't work right with apache I'm trying to compile PHP as a static apache module, and I get the following error: PATH=$PATH:/sbin ldconfig -n /usr/src/redhat/BUILD/php-4.3.0RC2/modules -- Libraries have been installed in: /usr/src/redhat/BUILD/php-4.3.0RC2/modules If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- gcc -Imain/ -I/usr/src/redhat/BUILD/php-4.3.0RC2/main/ -DPHP_ATOM_INC -I/usr/sr c/redhat/BUILD/php-4.3.0RC2/include -I/usr/src/redhat/BUILD/php-4.3.0RC2/main -I /usr/src/redhat/BUILD/php-4.3.0RC2 -I/usr/src/redhat/BUILD/php-4.3.0RC2/Zend -I/ usr/local/include -I/usr/include/imap -I/usr/src/redhat/BUILD/php-4.3.0RC2/ext/x ml/expat -I/usr/src/redhat/BUILD/php-4.3.0RC2/TSRM -g -O2 -c main/internal_fu nctions_cli.c -o main/internal_functions_cli.o echo main/internal_function s_cli.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst 1/lib -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix /lib/esql -L/usr/src/redhat/BUILD/php-4.3.0RC2/ext/informix -R /usr/local/lib - R /usr/local/Informix/lib -R /usr/local/Informix/lib/esql -R /usr/src/redhat/BUI LD/php-4.3.0RC2/ext/informix ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext /bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmat h/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src /neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.l o ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libb cmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src /int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output .lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcma th/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/ src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/nu m2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ex t/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext/fdf/fdf.lo ext/imap/php _imap.lo ext/informix/ifx.lo ext/ldap/ldap.lo ext/mysql/php_mysql.lo ext/mysql/l ibmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/m ysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_in it.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/lib mysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create .lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/l ibmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.l o ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql /my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mys ql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dir name.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql /libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_allo c.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/lib mysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpa th.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mys ql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/strin g.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/l ibmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/my sql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo e xt/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/st rmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/li bmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/ strcend.lo
#20928 [Bgs-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: I actually added the LDFLAGS myself to try and get things to start working. When you set up an instance (called db2inst1), it creates symbolic links in the instance directory to the /usr/IBMdb2/V7.1 directory for all the commands, libraries, and utilities. So LDFLAGS can be set to either, it really doesn't matter. Previous Comments: [2002-12-11 00:24:49] [EMAIL PROTECTED] You're passing the configure a different path to the DB2 install directory and then you set LDFLAGS to something else. Not PHP bug, user error. [2002-12-10 20:11:40] [EMAIL PROTECTED] I'm trying to compile PHP as a static apache module, and I get the following error: PATH=$PATH:/sbin ldconfig -n /usr/src/redhat/BUILD/php-4.3.0RC2/modules -- Libraries have been installed in: /usr/src/redhat/BUILD/php-4.3.0RC2/modules If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- gcc -Imain/ -I/usr/src/redhat/BUILD/php-4.3.0RC2/main/ -DPHP_ATOM_INC -I/usr/sr c/redhat/BUILD/php-4.3.0RC2/include -I/usr/src/redhat/BUILD/php-4.3.0RC2/main -I /usr/src/redhat/BUILD/php-4.3.0RC2 -I/usr/src/redhat/BUILD/php-4.3.0RC2/Zend -I/ usr/local/include -I/usr/include/imap -I/usr/src/redhat/BUILD/php-4.3.0RC2/ext/x ml/expat -I/usr/src/redhat/BUILD/php-4.3.0RC2/TSRM -g -O2 -c main/internal_fu nctions_cli.c -o main/internal_functions_cli.o echo main/internal_function s_cli.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst 1/lib -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix /lib/esql -L/usr/src/redhat/BUILD/php-4.3.0RC2/ext/informix -R /usr/local/lib - R /usr/local/Informix/lib -R /usr/local/Informix/lib/esql -R /usr/src/redhat/BUI LD/php-4.3.0RC2/ext/informix ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext /bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmat h/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src /neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.l o ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libb cmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src /int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output .lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcma th/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/ src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/nu m2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ex t/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext/fdf/fdf.lo ext/imap/php _imap.lo ext/informix/ifx.lo ext/ldap/ldap.lo ext/mysql/php_mysql.lo ext/mysql/l ibmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/m ysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_in it.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/lib mysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create .lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/l ibmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.l o ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql /my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mys ql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dir name.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql /libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_allo c.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/lib mysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpa th.lo
#20928 [Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: BTW, when I look at the command that compiles apache, it is clearly missing the -L/home/db2inst1/sqllib/lib in the list of library paths. This is the reason it's failing. I don't know how to add that path so that make in the apache dir will pick it up properly. Previous Comments: [2002-12-11 00:43:16] [EMAIL PROTECTED] I actually added the LDFLAGS myself to try and get things to start working. When you set up an instance (called db2inst1), it creates symbolic links in the instance directory to the /usr/IBMdb2/V7.1 directory for all the commands, libraries, and utilities. So LDFLAGS can be set to either, it really doesn't matter. [2002-12-11 00:24:49] [EMAIL PROTECTED] You're passing the configure a different path to the DB2 install directory and then you set LDFLAGS to something else. Not PHP bug, user error. [2002-12-10 20:11:40] [EMAIL PROTECTED] I'm trying to compile PHP as a static apache module, and I get the following error: PATH=$PATH:/sbin ldconfig -n /usr/src/redhat/BUILD/php-4.3.0RC2/modules -- Libraries have been installed in: /usr/src/redhat/BUILD/php-4.3.0RC2/modules If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. -- gcc -Imain/ -I/usr/src/redhat/BUILD/php-4.3.0RC2/main/ -DPHP_ATOM_INC -I/usr/sr c/redhat/BUILD/php-4.3.0RC2/include -I/usr/src/redhat/BUILD/php-4.3.0RC2/main -I /usr/src/redhat/BUILD/php-4.3.0RC2 -I/usr/src/redhat/BUILD/php-4.3.0RC2/Zend -I/ usr/local/include -I/usr/include/imap -I/usr/src/redhat/BUILD/php-4.3.0RC2/ext/x ml/expat -I/usr/src/redhat/BUILD/php-4.3.0RC2/TSRM -g -O2 -c main/internal_fu nctions_cli.c -o main/internal_functions_cli.o echo main/internal_function s_cli.lo /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/home/db2inst 1/lib -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix /lib/esql -L/usr/src/redhat/BUILD/php-4.3.0RC2/ext/informix -R /usr/local/lib - R /usr/local/Informix/lib -R /usr/local/Informix/lib/esql -R /usr/src/redhat/BUI LD/php-4.3.0RC2/ext/informix ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext /bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmat h/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src /neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.l o ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libb cmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src /int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output .lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcma th/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/ src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/nu m2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ex t/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext/fdf/fdf.lo ext/imap/php _imap.lo ext/informix/ifx.lo ext/ldap/ldap.lo ext/mysql/php_mysql.lo ext/mysql/l ibmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/m ysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_in it.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/lib mysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create .lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/l ibmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.l o ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql /my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mys ql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo
#20928 [Fbk-Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: It got much further this time, but results are the same. Here is the paste of the last command and error: === src/modules/throttle === src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-200212110630/ext/informix -rdynamic -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr /src/redhat/BUILD/php4-200212110630/ext/informix -Lmodules/php4 -L../modules/php 4 -L../../modules/php4 -lmodphp4 -ldb2 -lcrypto -lssl -lc-client -lifsql -lifa sf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informi x/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/redhat/BUILD/p hp4-200212110630/ext/informix -rdynamic -rdynamic -L/usr/local/lib -L/usr/local /Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-200212 110630/ext/informix -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodp hp4 -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ld l -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lc rypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.89498 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.89498 (%build) Previous Comments: [2002-12-11 00:48:46] [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-12-11 00:46:35] [EMAIL PROTECTED] BTW, when I look at the command that compiles apache, it is clearly missing the -L/home/db2inst1/sqllib/lib in the list of library paths. This is the reason it's failing. I don't know how to add that path so that make in the apache dir will pick it up properly. [2002-12-11 00:43:16] [EMAIL PROTECTED] I actually added the LDFLAGS myself to try and get things to start working. When you set up an instance (called db2inst1), it creates symbolic links in the instance directory to the /usr/IBMdb2/V7.1 directory for all the commands, libraries, and utilities. So LDFLAGS can be set to either, it really doesn't matter. [2002-12-11 00:24:49] [EMAIL PROTECTED] You're passing the configure a different path to the DB2 install directory and then you set LDFLAGS to something else. Not PHP bug, user error. [2002-12-10 20:11:40] [EMAIL PROTECTED] I'm trying to compile PHP as a static apache module, and I get the following error: PATH=$PATH:/sbin ldconfig -n /usr/src/redhat/BUILD/php-4.3.0RC2/modules -- Libraries have been installed in: /usr/src/redhat/BUILD/php-4.3.0RC2/modules If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add
#19349 [NoF-Opn]: odbc_longreadlen() does not work
ID: 19349 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.2.1 New Comment: Script is pretty simple. It's hard to just cut and paste because I have everything spread out in a bunch of classes. $linkid = odbc_pconnect(database, username, password); $result = odbc_exec($linkid, SELECT SUBSTR(document, 1, 200) FROM documents WHERE doc_id = 1); odbc_longreadlen($result, 200); odbc_binmode($result, ODBC_BINMODE_PASSTHRU); $column = odbc_result($result, 1); // A short example of what I'm trying to do. // $column should be filled with up to 200 bytes of data. // By default, it's up to 4096 bytes of data, or whatever is // set in the php.ini file. Previous Comments: [2002-11-16 01:13:36] [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-11-02 14:51:11] [EMAIL PROTECTED] can you please provide the full script sample for this? I think I do see what is wrong, but want to make sure. [2002-09-11 10:27:31] [EMAIL PROTECTED] I have a script that runs a select statement from a 10MB CLOB field (among others). I run the following : odbc_longreadlen($resultid, 300); Then I run: $document = odbc_result($resultid, 2); The problem is, $document ends up with 4096 bytes of data (the default, NOT 300). If I edit php.ini and set up odbc_lrl to 200 in there, then $document ends up with 2MBin it. It acts like the function odbc_longreadlen does not work at all. I don't know how much more information I can give other than odbc_longreadlen does not seem to do anything at all. [2002-09-11 09:49:21] [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-09-10 20:33:11] [EMAIL PROTECTED] I am using PHP with ODBC (IBM DB2) support and since upgrading to 4.2.1 from 4.0.4pl1, my odbc_longreadlen() function no longer works. I have to set it in the configuration file now, as that is the only place that it works properly. In addition, when it's set above 200 in the config file, httpd starts taking 75% of the CPU (system, not user) and the data never gets to PHP. Am I hitting some type of limitation? How else do I get my 10MB CLOB out of DB2? -- Edit this bug report at http://bugs.php.net/?id=19349edit=1
