[PHP-DEV] Bug #14452 Updated: libphp4.so is not linking with *.la files
ID: 14452 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Linux Old PHP Version: 4.1.0 PHP Version: 4.1.0, 4.1.1 New Comment: I have sucessfully linked PHP4.1.1 to static libtool libraries with the following method: 1. ./configure in the 4.0.6 source directory 2. ./configure in the 4.1.1 source directory 3. copy the libtool from 4.0.6 to the 4.1.1 direcory 4. make 5. make install Obviously this is a little messy, but it does seem to work sucessfully. Regards, Glen Previous Comments: [2001-12-14 04:14:09] [EMAIL PROTECTED] MySQL was installed from RPM's a while ago: MySQL-3.22.21-2C1 MySQL-client-3.22.21-2C1 MySQL-devel-3.22.21-2C1 The system is a Cobalt Qube 2: Linux qube.dessol 2.0.34C51_SK #1 Mon Nov 29 07:59:59 CET 1999 mips unknown By the way, I also tried linking with libmcal.a which is installed in /usr/local/mcal/lib/. I used the configuration option --with-mcal=/usr/local/mcal and configuration/compiling/installing went fine. However, when restarting Apache, I get: Cannot load /usr/lib/apache/libphp4.so into server: /usr/ lib/apache/libphp4.so: undefined symbol: mcal_close I don't know what's going on here, but it seems the *.a files are not being linked to correctly? There was no such problems with the 4.0.6 release which I compilied with MySQL and MCAL support with no problems. Thanks. [2001-12-13 23:55:23] [EMAIL PROTECTED] How exactly did you configure/compile/install Mysql ? And what linux distribution is this ? --Jani [2001-12-13 06:18:31] [EMAIL PROTECTED] I deleted the libmysqlclient.la file from /usr/lib/mysql and tried re-compiling, but still got the same error. [2001-12-12 12:45:29] [EMAIL PROTECTED] I guess you're getting the libtool bug I noticed myself too. Try deleting the .la file. --Jani [2001-12-12 07:47:06] [EMAIL PROTECTED] I have configured PHP with the following options: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr /usr/lib/mysql contains libmyclient.a and libmyclient.sa. Configuration and make goes fine, though I get the following warning: *** Warning: This library needs some functionality provided by /usr/lib/mysql/libmysqlclient.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Install goes fine, but when I restart Apache ( 1.3.3 ), I get the following error: Cannot load /usr/lib/apache/libphp4.so into server: /usr/ lib/apache/libphp4.so: undefined symbol: mysql_free_result PHP 4.0.6 compiled from source and ran with no such problems. Edit this bug report at http://bugs.php.net/?id=14452edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14452: libphp4.so is not linking with *.la files
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: *Configuration Issues Bug description: libphp4.so is not linking with *.la files I have configured PHP with the following options: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr /usr/lib/mysql contains libmyclient.a and libmyclient.sa. Configuration and make goes fine, though I get the following warning: *** Warning: This library needs some functionality provided by /usr/lib/mysql/libmysqlclient.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Install goes fine, but when I restart Apache ( 1.3.3 ), I get the following error: Cannot load /usr/lib/apache/libphp4.so into server: /usr/ lib/apache/libphp4.so: undefined symbol: mysql_free_result PHP 4.0.6 compiled from source and ran with no such problems. -- Edit bug report at: http://bugs.php.net/?id=14452edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13303: cURL fails over SSL
From: [EMAIL PROTECTED] Operating system: Cobalt Linux 5.0 PHP version: 4.0.6 PHP Bug Type: cURL related Bug description: cURL fails over SSL Using cURL over SSL always seems to return a 0 byte file. Using cURL with normal URL's works fine. Using the command-line cURL over SSL works fine. This is with libcurl 7.8.1 built with OpenSSL 0.9.6a. -- Edit bug report at: http://bugs.php.net/?id=13303edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11363 Updated: Apache fails to start
ID: 11363 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: *Encryption and hash functions Operating system: Cobalt OS 4.0 PHP Version: 4.0.5/6 Description: Apache fails to start These are taken from the 4.0.6 release ( which has the same problem as 4.0.5 ): HAVE_RANDOM 1 HAVE_SRAND48 1 Previous Comments: --- [2001-06-28 23:13:08] [EMAIL PROTECTED] What are these constants set as in your main/php_config.h: HAVE_SRANDOM HAVE_SRAND48 --Jani --- [2001-06-15 10:19:06] [EMAIL PROTECTED] Here is the output I get from gdb: Starting program: /usr/sbin/httpd -X Program received signal SIGFPE, Arithmetic exception. 0x2ae4c000 in php_minit_crypt (type=1, module_number=2) at crypt.c:105 105 php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0)); --- [2001-06-08 13:44:17] [EMAIL PROTECTED] I configured PHP4.0.5 with: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr which configured fine. I compiled and installed with no problems. When I came to restart Apache ( version 1.3.3 ), with /etc/rc.d/init.d/httpd restart I get: Shutting down http: httpd Starting http: httpd which usually indicates Apache has restarted okay. However, Apache is now not running and I cannot access any webpages on the server. The server is a Cobalt Qube2. Many thanks, Glen Scott --- Full Bug description available at: http://bugs.php.net/?id=11363 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11363 Updated: Apache fails to start
ID: 11363 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: *Encryption and hash functions Operating system: Cobalt OS 4.0 PHP Version: 4.0.5/6 Description: Apache fails to start sorry, that should be HAVE_SRANDOM 1 -Glen Previous Comments: --- [2001-06-29 03:57:57] [EMAIL PROTECTED] These are taken from the 4.0.6 release ( which has the same problem as 4.0.5 ): HAVE_RANDOM 1 HAVE_SRAND48 1 --- [2001-06-28 23:13:08] [EMAIL PROTECTED] What are these constants set as in your main/php_config.h: HAVE_SRANDOM HAVE_SRAND48 --Jani --- [2001-06-15 10:19:06] [EMAIL PROTECTED] Here is the output I get from gdb: Starting program: /usr/sbin/httpd -X Program received signal SIGFPE, Arithmetic exception. 0x2ae4c000 in php_minit_crypt (type=1, module_number=2) at crypt.c:105 105 php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0)); --- [2001-06-08 13:44:17] [EMAIL PROTECTED] I configured PHP4.0.5 with: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr which configured fine. I compiled and installed with no problems. When I came to restart Apache ( version 1.3.3 ), with /etc/rc.d/init.d/httpd restart I get: Shutting down http: httpd Starting http: httpd which usually indicates Apache has restarted okay. However, Apache is now not running and I cannot access any webpages on the server. The server is a Cobalt Qube2. Many thanks, Glen Scott --- Full Bug description available at: http://bugs.php.net/?id=11363 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11690: apxs does not support -S
From: [EMAIL PROTECTED] Operating system: Cobalt OS 5.0 (RaQ3) PHP version: 4.0.6 PHP Bug Type: *Install and Config Bug description: apxs does not support -S I currently have PHP4.0.4pl1 running fine on a Cobalt RaQ3 machine, and I attempted to upgrade to version 4.0.6. The configure and make went okay with no errors reported, but 'make install' fails with the following error: --- Making install in . make[1]: Entering directory `/home/sites/home/users/admin/php-4.0.6' /home/sites/home/users/admin/php-4.0.6/build/shtool mkdir -p /usr/lib/apache /usr/sbin/apxs -S LIBEXECDIR=/usr/lib/apache -i -a -n php4 libs/libphp4.so apxs:Error: Unknown option: S Usage: apxs -g -n modname apxs -q query ... apxs -c [-o dsofile] [-D name[=value]] [-I incdir] [-L libdir] [-l libname] [-Wc,flags] [-Wl,flags] files ... apxs -i [-a] [-A] [-n modname] dsofile ... make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/home/sites/home/users/admin/php-4.0.6' make: *** [install-recursive] Error 1 --- It seems the PHP install is trying to install the DSO module with an option that apxs doesn't support ( -S ). The RaQ3 is running Apache version 1.3.6. Regards, Glen Scott -- Edit Bug report at: http://bugs.php.net/?id=11690edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11363 Updated: Apache fails to start
ID: 11363 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating system: Cobalt OS 4.0 PHP Version: 4.0.5 Description: Apache fails to start Here is the output I get from gdb: Starting program: /usr/sbin/httpd -X Program received signal SIGFPE, Arithmetic exception. 0x2ae4c000 in php_minit_crypt (type=1, module_number=2) at crypt.c:105 105 php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0)); Previous Comments: --- [2001-06-08 13:44:17] [EMAIL PROTECTED] I configured PHP4.0.5 with: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr which configured fine. I compiled and installed with no problems. When I came to restart Apache ( version 1.3.3 ), with /etc/rc.d/init.d/httpd restart I get: Shutting down http: httpd Starting http: httpd which usually indicates Apache has restarted okay. However, Apache is now not running and I cannot access any webpages on the server. The server is a Cobalt Qube2. Many thanks, Glen Scott --- Full Bug description available at: http://bugs.php.net/?id=11363 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10565: mysql_real_connect dumps core, fix included
From: [EMAIL PROTECTED] Operating system: SCO OpenServer 5.0.6 PHP version: 4.0.4pl1 PHP Bug Type: MySQL related Bug description: mysql_real_connect dumps core, fix included ** This is a problem in MySql. This report provides a code modification to compensate for the MySql problem. ** Under SCO OpenServer 5.0.6, Apache 1.3.19, PHP 4.0.4 PL 1, and MySql 3.23.36 (precompiled MySQL for OpenServer 5.0.x), calls to mysql_real_connect will silently dump core if mysql_init was not allowed to *allocate* the memory for the MySQL structure. To function properly, mysql_init must be passed NULL, thus allowing it to allocate and manage the memory. If you use a previously malloc()'ed or static structure, MySQL will dump core on connect. We find this problem to be present in MySQL, and can duplicate it using a C code stub. The problem, of course, also exists in PHP, causing a core dump there as well, since PHP pre-malloc()'s its own structure. Here is a DIFF for ext/mysql/php_mysql.c which fixes the problem for us. It's ugly, and hack-y, but it works. FYI. 198c198 efree(link); --- /* efree(link); */ 456c456 mysql = (MYSQL *) malloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) malloc(sizeof(MYSQL)); */ 458c458 mysql_init(mysql); --- mysql = mysql_init(NULL); 542c542 mysql = (MYSQL *) emalloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) emalloc(sizeof(MYSQL)); */ 544c544 mysql_init(mysql); --- mysql = mysql_init(NULL); -- Edit Bug report at: http://bugs.php.net/?id=10565edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9550: function missing from .c file
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.4pl1 PHP Bug Type: Sybase-ct (ctlib) related Bug description: function missing from .c file The following lines are needed in the file php_sybase_ct.c PHP_FE(sybase_field_seek, NULL) PHP_FALIAS(mssql_field_seek,sybase_field_seek,NULL) They appear to have been left out. -- Edit Bug report at: http://bugs.php.net/?id=9550edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8940 Updated: File uploads stopped withing in 4.0.4pl1
ID: 8940
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Description: File uploads stopped withing in 4.0.4pl1
Ok, I've done some further testing. With a simple script that does
nothing except upload the file and move it, it works: the file is
there. However, the "type" variable has no value! No matter what
type of file I upload, the $HTTP_POST_FILES['userfile']['type'] value
is an empty string.
Previous Comments:
---
[2001-01-26 11:21:21] [EMAIL PROTECTED]
I've been using 4.0.3 for a couple of weeks now. Last night I ran the
Redhat Update agent and installed 4.0.4pl1. Everything works fine
except for file uploads. The upload is recorded as successful,
everything SEEMS to work fine, but there is no file in /tmp, and the
variable $HTTP_POST_FILES['userfile']['type'] is undefined. Apache
1.3.14 reports no problems, and returns a 200 return code. I've
tried working with php.ini; I can turn file uploads off, and that
works, then when I turn it back on again, it has the same problem.
I'm pretty sure it's something in 4.0.4pl1 because nothing else on
my system has changed since the upgrade last night. Here's some of
my code:
$file_type = $HTTP_POST_FILES['userfile']['type'];
if (substr($file_type,-4,4) != 'jpeg') {
die( "Files of type '" . $file_type .
"' are not recognized.br" .
"Only JPEG images are currently supported."
);
}
$path_for_file = 'gallery/' . $user_id . '/' . $photo_id .
'.jpg';
if
(!is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
die( "File is not uploaded." );
move_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name'],
$path_for_file);
...but I really don't think the problem is in the code. Here's some
output from my Apache log file:
192.168.1.2 - - [26/Jan/2001:08:13:04 -0800] "POST /upload.php
HTTP/1.1" 200 51
"http://mysite/upload.php" "Mozilla/4.0 (compatible; MSIE 5.0;
Mac_PowerPC)
"
No errors are reported any where.
---
Full Bug description available at: http://bugs.php.net/?id=8940
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8940 Updated: File uploads stopped withing in 4.0.4pl1
ID: 8940
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Description: File uploads stopped withing in 4.0.4pl1
Further testing reveals that the upload is working properly, but the
file 'type' variable is not set, and PHP is not treating it as an image
file. Image processing utilities state that the file is corrupt after
uploading, even though it remains the exact same size as the
original. I suspect that PHP is doing something to the file.
Previous Comments:
---
[2001-01-26 12:01:45] [EMAIL PROTECTED]
Ok, I've done some further testing. With a simple script that does
nothing except upload the file and move it, it works: the file is
there. However, the "type" variable has no value! No matter what
type of file I upload, the $HTTP_POST_FILES['userfile']['type'] value
is an empty string.
---
[2001-01-26 11:21:21] [EMAIL PROTECTED]
I've been using 4.0.3 for a couple of weeks now. Last night I ran the
Redhat Update agent and installed 4.0.4pl1. Everything works fine
except for file uploads. The upload is recorded as successful,
everything SEEMS to work fine, but there is no file in /tmp, and the
variable $HTTP_POST_FILES['userfile']['type'] is undefined. Apache
1.3.14 reports no problems, and returns a 200 return code. I've
tried working with php.ini; I can turn file uploads off, and that
works, then when I turn it back on again, it has the same problem.
I'm pretty sure it's something in 4.0.4pl1 because nothing else on
my system has changed since the upgrade last night. Here's some of
my code:
$file_type = $HTTP_POST_FILES['userfile']['type'];
if (substr($file_type,-4,4) != 'jpeg') {
die( "Files of type '" . $file_type .
"' are not recognized.br" .
"Only JPEG images are currently supported."
);
}
$path_for_file = 'gallery/' . $user_id . '/' . $photo_id .
'.jpg';
if
(!is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
die( "File is not uploaded." );
move_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name'],
$path_for_file);
...but I really don't think the problem is in the code. Here's some
output from my Apache log file:
192.168.1.2 - - [26/Jan/2001:08:13:04 -0800] "POST /upload.php
HTTP/1.1" 200 51
"http://mysite/upload.php" "Mozilla/4.0 (compatible; MSIE 5.0;
Mac_PowerPC)
"
No errors are reported any where.
---
Full Bug description available at: http://bugs.php.net/?id=8940
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #8940 Updated: File uploads stopped withing in 4.0.4pl1
ID: 8940
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Description: File uploads stopped withing in 4.0.4pl1
If you view the uploaded file (using "od" in my case), you'll see that
the first few bytes of it are:
"Content-Type: image/jpeg" followed by the binary data that makes
up the JPEG file. Since the uploaded file is exactly the same size as
the original, I presume that the last few bytes are dropped out.
Previous Comments:
---
[2001-01-26 12:50:56] [EMAIL PROTECTED]
Further testing reveals that the upload is working properly, but the
file 'type' variable is not set, and PHP is not treating it as an image
file. Image processing utilities state that the file is corrupt after
uploading, even though it remains the exact same size as the
original. I suspect that PHP is doing something to the file.
---
[2001-01-26 12:01:45] [EMAIL PROTECTED]
Ok, I've done some further testing. With a simple script that does
nothing except upload the file and move it, it works: the file is
there. However, the "type" variable has no value! No matter what
type of file I upload, the $HTTP_POST_FILES['userfile']['type'] value
is an empty string.
---
[2001-01-26 11:21:21] [EMAIL PROTECTED]
I've been using 4.0.3 for a couple of weeks now. Last night I ran the
Redhat Update agent and installed 4.0.4pl1. Everything works fine
except for file uploads. The upload is recorded as successful,
everything SEEMS to work fine, but there is no file in /tmp, and the
variable $HTTP_POST_FILES['userfile']['type'] is undefined. Apache
1.3.14 reports no problems, and returns a 200 return code. I've
tried working with php.ini; I can turn file uploads off, and that
works, then when I turn it back on again, it has the same problem.
I'm pretty sure it's something in 4.0.4pl1 because nothing else on
my system has changed since the upgrade last night. Here's some of
my code:
$file_type = $HTTP_POST_FILES['userfile']['type'];
if (substr($file_type,-4,4) != 'jpeg') {
die( "Files of type '" . $file_type .
"' are not recognized.br" .
"Only JPEG images are currently supported."
);
}
$path_for_file = 'gallery/' . $user_id . '/' . $photo_id .
'.jpg';
if
(!is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
die( "File is not uploaded." );
move_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name'],
$path_for_file);
...but I really don't think the problem is in the code. Here's some
output from my Apache log file:
192.168.1.2 - - [26/Jan/2001:08:13:04 -0800] "POST /upload.php
HTTP/1.1" 200 51
"http://mysite/upload.php" "Mozilla/4.0 (compatible; MSIE 5.0;
Mac_PowerPC)
"
No errors are reported any where.
---
Full Bug description available at: http://bugs.php.net/?id=8940
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
