Req #43177 [Com]: Errors in eval()'ed code produce status code 500
Edit report at https://bugs.php.net/bug.php?id=43177&edit=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: --- --- 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 nic
Req #43177 [Com]: Errors in eval()'ed code produce status code 500
Edit report at https://bugs.php.net/bug.php?id=43177&edit=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: --- --- 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: Result: # curl -I http://localhost/test.php HTTP/1.0 500 Internal Server Error
Bug #62129 [Com]: rfc1867 crashes php even though turned off
Edit report at https://bugs.php.net/bug.php?id=62129&edit=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=) 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=) at /cns/build/php-5.4.3/ext/session/session.c:2388 #104650 0x00473841 in rfc1867_post_handler ( content_type_dup=, arg=0x11535e8) at /cns/build/php-5.4.3/main/rfc1867.c:773 #104651 0x00471372 in sapi_handle_post (arg=) at /cns/build/php-5.4.3/main/SAPI.c:182 #104652 0x0067efd8 in mbstr_treat_data (arg=0, str=0x0, destArray=) 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 ) 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=, 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 } 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, extra TSRMLS_CC); - } if (!PS
[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=62129&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62129&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62129&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62129&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62129&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62129&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62129&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62129&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62129&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62129&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62129&r=support Expected behavior: https://bugs.php.net/fix.php?id=62129&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62129&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62129&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62129&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62129&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62129&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62129&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62129&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62129&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62129&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62129&r=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: --- 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=34551&edit=1
#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: --- 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=34551&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34551&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34551&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34551&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34551&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34551&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34551&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34551&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34551&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34551&r=support Expected behavior: http://bugs.php.net/fix.php?id=34551&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34551&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34551&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34551&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34551&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34551&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34551&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34551&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34551&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34551&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34551&r=mysqlcfg
#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 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=22860&edit=1
#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 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=22860&edit=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=22860&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22860&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22860&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22860&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22860&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22860&r=support Expected behavior: http://bugs.php.net/fix.php?id=22860&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22860&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22860&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22860&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22860&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22860&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22860&r=gnused
#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=22593&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22593&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22593&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22593&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22593&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22593&r=support Expected behavior: http://bugs.php.net/fix.php?id=22593&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22593&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22593&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22593&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22593&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22593&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22593&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22593&r=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 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 Ze
#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
#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=19349&edit=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/st
#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.
#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/inform
#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 -
#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 ext/mysql/li
#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 ext/
#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 ext/mysql/lib
#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=19349&edit=1
Bug #15177 Updated: Informix Shared Module will not compile
ID: 15177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: *Compile Issues Operating System: RH Linux 7.2 PHP Version: 4.1.1 New Comment: This might possibly be related to bug number 15803 as this is the last time (php-4.0.4pl1) I was able to compile Informix with IBM DB2 support at the same time as well... Previous Comments: [2002-03-03 05:34:47] [EMAIL PROTECTED] Marking as Critical for release 4.2.0 [2002-03-03 05:30:06] [EMAIL PROTECTED] The last version where compile with-informix worked was php4-4.0.4pl1 None after that work, I've tryed them all, including snapshots [2002-01-23 00:45:02] [EMAIL PROTECTED] Same problem as with 4.1.0. Informix will compile statically in PHP, but will not compile as a shared module. I get the same error as in 4.1.0: /bin/sh /php/php-4.1.1/libtool --silent --mode=compile gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -c ifx.c && touch ifx.slo /bin/sh /php/php-4.1.1/libtool --silent --mode=link gcc -I. -I/php/php-4.1.1/ext/informix -I/php/php-4.1.1/main -I/php/php-4.1.1 -I/usr/include/apache -I/php/php-4.1.1/Zend -I/opt/informix/incl/esql -I/php/php-4.1.1/ext/xml/expat -DLINUX=22 -DEAPI -DEAPI_MM -DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/php/php-4.1.1/TSRM -g -O2 -prefer-pic -o informix.la -avoid-version -module -rpath /php/php-4.1.1/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 make[3]: Leaving directory `/php/php-4.1.1/ext/informix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/php/php-4.1.1/ext/informix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/php/php-4.1.1/ext' make: *** [all-recursive] Error 1 Configure was input as [root@elliott php-4.1.1]# ./configure --with-apxs=/usr/sbin/apxs --without-mysql --enable-shared --with-informix=shared Any ideas? Zack -- Edit this bug report at http://bugs.php.net/?id=15177&edit=1