Bug #60696 [Opn->Fbk]: Large Integers problem
Edit report at https://bugs.php.net/bug.php?id=60696&edit=1 ID: 60696 Updated by: paj...@php.net Reported by:danhen at web dot de Summary:Large Integers problem -Status: Open +Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: There is nothing we can do about 64bit integer now on Windows in 5.x. It requires a lot of changes in the engine and in all extensions (basically using int64_t instead of long, along with other API changes). About the sqlsrv drive, I do not see how it could be remotely related. Are you saying that this happen only when an error happens before the connect? I tried locally and everything worked fine. Is this the exact code you are using to test? Previous Comments: [2013-03-30 00:53:21] ras...@php.net We have very few Windows developers. Submit a patch please. [2013-03-29 17:40:20] aaron at steamcube dot com Still broken with 5.4.13, 13 months later. [2012-04-26 05:04:44] danhen at web dot de Have tried other PDO-Drivers. It only happens on pdo_sqlsrv. So what was changed in 5.4 integer Handling? The broken Code in 5.4 works fine in 5.3 and earlier Versions. [2012-04-03 01:39:51] yohg...@php.net Could you or anyone try see if this happens with other PDO drivers? $iTest is overflowed (i.e. larger than 31^2), but this should not matter. [2012-01-10 05:20:22] danhen at web dot de Description: If large integer values ââare defined in the source code, connecting to MSSQL-Server fails. Setup: Windows Vista PHP5.4 RC5 php_pdo_sqlsrv as additional extension The code which defines the value doesn't need to be executed. It's enough defining such values before connecting to mssql (inside a previous loadad class in my case). When 90 is changed to 9 everything is fine. Test script: --- https://bugs.php.net/bug.php?id=60696&edit=1
Bug #60696 [Opn]: Large Integers problem
Edit report at https://bugs.php.net/bug.php?id=60696&edit=1 ID: 60696 Updated by: ras...@php.net Reported by:danhen at web dot de Summary:Large Integers problem Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: We have very few Windows developers. Submit a patch please. Previous Comments: [2013-03-29 17:40:20] aaron at steamcube dot com Still broken with 5.4.13, 13 months later. [2012-04-26 05:04:44] danhen at web dot de Have tried other PDO-Drivers. It only happens on pdo_sqlsrv. So what was changed in 5.4 integer Handling? The broken Code in 5.4 works fine in 5.3 and earlier Versions. [2012-04-03 01:39:51] yohg...@php.net Could you or anyone try see if this happens with other PDO drivers? $iTest is overflowed (i.e. larger than 31^2), but this should not matter. [2012-01-10 05:20:22] danhen at web dot de Description: If large integer values ââare defined in the source code, connecting to MSSQL-Server fails. Setup: Windows Vista PHP5.4 RC5 php_pdo_sqlsrv as additional extension The code which defines the value doesn't need to be executed. It's enough defining such values before connecting to mssql (inside a previous loadad class in my case). When 90 is changed to 9 everything is fine. Test script: --- https://bugs.php.net/bug.php?id=60696&edit=1
Bug #64548 [Opn->Nab]: Last Month (feb/march issue)
Edit report at https://bugs.php.net/bug.php?id=64548&edit=1
ID: 64548
Updated by: ras...@php.net
Reported by:timothymarois at gmail dot com
Summary:Last Month (feb/march issue)
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Sorry, but this is really not a bug. This is how most UNIX-based tools do
relative date math. For better or worse, it is the standard. Try it from your
Linux command line:
$ date
Fri Mar 29 17:16:02 PDT 2013
$ date --date='-1 month' +'Last month was %B?'
Last month was March?
Or in Sqlite:
sqlite> select datetime('2013-03-29', '-1 month');
2013-03-01 00:00:00
We decided to follow convention here. There is a GNU doc on it here:
http://www.gnu.org/software/tar/manual/html_node/Relative-items-in-date-
strings.html#SEC120
And there really is no good answer. 3/29 - 1 month would be 2/29 but that date
doesn't exist. So, what do you do? Do you subtract 1 month and 1 day and return
2/28? That's not very precise. Given the fact that there is no right answer
here, we followed convention. To do proper relative date math you need to be
more explicit about what you actually want. As in "first day of last month"
Previous Comments:
[2013-03-29 15:07:52] timothymarois at gmail dot com
Description:
At the moment, because today is March 29th, my script using
date("F Y",strtotime('-1 Month')) or date("F Y",strtotime('Last Month'))
Shows March 2013 (a few days ago it showed February 2013) I believe this is due
to
feb's short days. I did some testing to it, if I where to do
date("F Y",strtotime('-2 Month')) the output is January 2013, thats current to
the
current date.
This would be a bug due to php's capabilities in resolving actual calendar days.
I've seen postings that "this is not a bug" but it is, you can't have a script
designed to give calendar day results, and have it given the wrong results out.
Its incorrect and needs to be resolves. PHP is the software, and the software
should be patched to give the current calendar days.
Test script:
---
date("F Y",strtotime('Last Month'))
Expected result:
February 2013
Actual result:
--
March 2013
--
Edit this bug report at https://bugs.php.net/bug.php?id=64548&edit=1
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at https://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Comment by: ricardojdn at gmail dot com Reported by:tec at baufi24 dot de Summary:number_format() fails (randomly?) Status: Wont fix Type: Bug Package:Math related Operating System: Windows PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: I've created a new PHP5.3.1VC9-windows compilation with mssql and the problem has been solved. My PC: Windows 7 + Apache 2.2 + SQLServer2008 + (my)PHP5.3.1VC9 Previous Comments: [2012-03-08 11:28:03] paj...@php.net VC9 builds do not have this problem anymore and we do not support VC6 anymore. [2010-11-18 07:19:00] tec at baufi24 dot de The solution for this bug is to use the right PHP version for Windows Server. If you use IIS then you have to install a VC9 Version. http://windows.php.net/download/ [2010-11-18 00:07:16] adenman at tmea dot org A follow-up: I just created a new site on the server for other testing and the test site does not exhibit this behavior. The test site is completely separate from the main site, but I've copied the settings exactly from the main site and am using the same PHP executable and an exact copy of the php.ini file. I've run diffs on several configuration files and cannot find any differences other than name and site paths. With both sites running on the server, I ran the test several times on each. The main site always gives me '16.:' (wrong) and the test site always gives me '17' (correct). I have no idea what this means, but figured it might be helpful to someone looking into this. [2010-09-01 19:40:46] adenman at tmea dot org I am able to reproduce this. PHP: 5.2.13 OS: Windows 2008 Standard Server, 64-bit (Windows NT WEB2 6.1 build 7600 from phpinfo) CPU: AMD Opteron 6172 Using the test posted by 'adrianv at taly dot net' on bug http://bugs.php.net/bug.php?id=47418 and changing to list whole numbers, I have found the following numbers exhibit this odd behavior: 17, 19, 29, 39 and multiples of ten of these numbers (170, 1700, 17000, etc) They get output as: 16.:0, 18.:0, 28.:0, 38.:0, etc when using the number_format or sprintf functions to format them with decimal places. In addition to number_format and sprintf, I have found that once you do basic math with these numbers and float numbers, even just echoing the result will trigger this bug. The bcmath functions do not exhibit this behavior. Example: $tot = 17; $math = $tot * 1.5; $math = $math / 1.5; $math2 = bcmul($tot, 1.5, 1); $math2 = bcdiv($math2, 1.5, 1); echo $math //outputs 16.:, expect 17 echo $math2 //outputs 17.0, expect 17.0 [2010-08-04 13:15:33] codeslinger at compsalot dot com it's not random, it's just very hard to reproduce. only certain specific values will trigger this bug. and the weird thing is that the specific value changes from build to build and with different oses. this bug is a dup of the many other existing reports about this bug. bugs 43487, 47304, 47716, 47732, 51396 etc.. this bug has been encountered in: php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9... it has been found on Windows 2000, Windows XP, Windows 2003, ubuntu, mandriva. This bug has been reproduced both with and without xdebug and/or zend debugger. You want to reproduce this bug???!!! it's very easy, I will give you a one-liner install ubuntu 8.0.4 install the standard php that comes with ubuntu 8.0.4 now run this: echo (string) (double) -0.0; actual result: -0.0: Note that changing the float percision greatly affects the bug. The thing is that the value is very specific to the actual build and the actual os. For instance it was reported that on Windows nt 5.2 (2003?) the following will fail: echo round(1451,2); actual result: 1450.:0 It has also been reported that using BCMath helps but does not totally solve this problem "3 out of 4 were fixed". But despite all of the above, this bug keeps getting blown off as not repro!!! :-( Consider the following true story: once upon a time, there was a German insurance company sued by a client whoâd lost a lot of money through the insurance companyâs flawed bookkeeping. The insurance company went into a panic and started hunting the bug and were able to prove it was caused by customized software theyâd bought from a German software house. They sued the software house. The software house went into a panic and started hunting the bug further. They were able to prove the
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1 ID: 61336 Comment by: stasismedia at gmail dot com Reported by:ram...@php.net Summary:file_get_contents() no longer returns false on 4xx responses Status: Open Type: Bug Package:Filesystem function related Operating System: CentOS 6.2 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: FYI, I experienced this issue when PHP was compiled with --with-curlwrappers Previous Comments: [2013-03-04 15:04:51] php at maisqi dot com Just noted that I gave a wrong URI to the script; sorry, here is the right one: http://maisqi.com/outros/bugs/php/61336 [2013-03-04 15:01:49] php at maisqi dot com vestigalorgan, you are right: it should return false in all three cases. Thanks for correcting. [2013-03-02 01:50:21] vestigalorgan at gmail dot com I've run the test case that maisqi provided, and here are my results: 1. Using file_file_get_contents() on an non-existing resource on a existing domain: The result: boolean $http_response_header: array 2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the context: The result: boolean $http_response_header: NULL 3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on the context: The result: boolean $http_response_header: NULL This is on Ubuntu 12.04 LTS 64-bit with Apache 2.2.22 and PHP 5.3.10-1ubuntu3.5 with the Suhosin-Patch. Everything appears to be working fine there. Shouldn't the output of the results be a boolean false, not NULL, maisqi? [2013-03-01 09:54:17] php at maisqi dot com I think I have new info on this issue. If you check the URI at the bottom you'll find three tests: 1. Using file_file_get_contents() on an non-existing resource on a existing domain: Result: empty string $http_response_header : an array 2. Using file_file_get_contents() on a non-existing domain, with follow_location => 0 on the context: Result: empty string $http_response_header : NULL 3. Using file_file_get_contents() on a non-existing domain, __without__ follow_location => 0 on the context: Result: non empty string $http_response_header : an array I'd expect that all the results should be NULL. I think the problem has to to with idiosyncratic behavior on some internal library. In the third test we can see that there's something asking OpenDNS when trying to deal with the non-existing behavior; and then it sends a Location header. This behavior is not documented. - The same script on a Windows 7/Apache Server [PHP 5.4.12] works as expected; - On a Debian 3.2.35-2 running PHP 5.2.5 it works as expected; - On a Turnkey Linux (Ubuntu based Linux) running PHP 5.3.3-7+squeeze14 it works as expected; - On a Ubuntu running PHP 5.3.3-7+squeeze14 it works as expected. So I'd say it has to do with the underlying system libraries and configuration; it would be nice if others test the script on other kind of servers... Test script: http://maisqi/outros/bugs/php/61336 [CentOS / PHP 5.4.11] [2013-01-14 23:52:39] vestigalorgan at gmail dot com I'm experiencing a similar issue in the PHP version 5.4.7 that ships with XAMPP. When I open a web URL that throws a warning such as "Warning: file_get_contents(http://[ip_address_here]:[port_here]): failed to open stream: No connection could be made because the target machine actively refused it.", file_get_contents() returns an empty string, instead of false. I'm not sure if this is related to this bug or I should file a new one. I'm experiencing this on Windows 7 Professional, SP1 32-bit. I'm only using the first parameter of file_get_contents(). 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 https://bugs.php.net/bug.php?id=61336 -- Edit this bug report at https://bugs.php.net/bug.php?id=61336&edit=1
Bug #49348 [Com]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
Edit report at https://bugs.php.net/bug.php?id=49348&edit=1 ID: 49348 Comment by: bugs dot php dot net at majkl578 dot cz Reported by:BelStudent at yandex dot ru Summary:Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!) Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: The message is not consistent with the other one triggered in similar case. Consider the following code: $x = new stdClass(); echo $x->foo++; echo $x->bar; It triggers two notices: Notice: Undefined property: foo Notice: Undefined property: stdClass::$bar The first one was added by fix for this bug and is wrong. It should be same as the other one (should contain classname and dollar). Previous Comments: [2013-02-21 08:58:40] s...@php.net Automatic comment on behalf of stas Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read [2013-02-20 08:35:21] dmi...@php.net I think the fix is fine, but it may go only into 5.5 and above. [2013-02-19 09:18:04] s...@php.net Potential fix in this pull: https://github.com/php/php-src/pull/281 [2013-02-19 04:59:16] s...@php.net The problem here is that get_property_ptr_ptr does not produce notices. It doesn't because it does not know the fetch type - in some cases it's BP_VAR_W, then it shouldn't produce notice, in some it's BP_VAR_RW and then it should. However get_property_ptr_ptr doesn't have a parameter to pass this info. Looks like such parameter needs to be added... [2009-09-01 08:41:52] sjo...@php.net I was talking about this: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251 With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With ++$this->foo, it is BP_VAR_W. 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 https://bugs.php.net/bug.php?id=49348 -- Edit this bug report at https://bugs.php.net/bug.php?id=49348&edit=1
Bug #60696 [Com]: Large Integers problem
Edit report at https://bugs.php.net/bug.php?id=60696&edit=1 ID: 60696 Comment by: aaron at steamcube dot com Reported by:danhen at web dot de Summary:Large Integers problem Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Still broken with 5.4.13, 13 months later. Previous Comments: [2012-04-26 05:04:44] danhen at web dot de Have tried other PDO-Drivers. It only happens on pdo_sqlsrv. So what was changed in 5.4 integer Handling? The broken Code in 5.4 works fine in 5.3 and earlier Versions. [2012-04-03 01:39:51] yohg...@php.net Could you or anyone try see if this happens with other PDO drivers? $iTest is overflowed (i.e. larger than 31^2), but this should not matter. [2012-01-10 05:20:22] danhen at web dot de Description: If large integer values ââare defined in the source code, connecting to MSSQL-Server fails. Setup: Windows Vista PHP5.4 RC5 php_pdo_sqlsrv as additional extension The code which defines the value doesn't need to be executed. It's enough defining such values before connecting to mssql (inside a previous loadad class in my case). When 90 is changed to 9 everything is fine. Test script: --- https://bugs.php.net/bug.php?id=60696&edit=1
[PHP-BUG] Bug #64549 [NEW]: mysqlnd persistent connection handling out of control
From: rgagnon24 at gmail dot com
Operating system: CentOS 5.9
PHP version: 5.3.23
Package: MySQL related
Bug Type: Bug
Bug description:mysqlnd persistent connection handling out of control
Description:
When PHP 5.3 is compiled with
--enable-mysqlnd=shared
--with-mysql=shared,mysqlnd
--with-mysqli=shared,mysqlnd
--with-pdo-mysql=shared,mysqlnd
In order to use the native driver, persistent connections using PDO don't
appear to use any kind of managable or determinate connection pooling.
Running the test script below via apache web server, refreshing the page
every few seconds (10 or 12 times), will produce at least 10 connections to
the database as shown by the mysql "SHOW PROCESSLIST" command... yet the
phpinfo() section will indicate a number that is not the same as the actual
number of connections.
In my test prior to posting, I had 10 actual connections (of which 9 were
sleeping, and the 10th one was just used to run the test query) and
phpinfo() showed 5 active_persistent_connections, and pconnect_success was
8 (under the mysqlnd stats section).
This leads me to believe there may be a memory leak in the area of code
where the module is managing the connection pool. If no memory leak, the
management of the connections is off somehow as idle connections to a
production webserver are ridiculously high.
Test script:
---
true,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true,
);
$host_name = 'database_host';
$database_name = 'some_database';
$port = 3306;
$username = 'db_user';
$password = 'db_pass';
$dsn = sprintf("mysql:host=%s;dbname=%s;port=%d",
$host_name, $database_name, $port);
$dbh = new PDO($dsn, $username, $password, $options);
$sql = 'SELECT * FROM test WHERE id=1 LIMIT 1';
print "";
$stmt = $dbh->query($sql, PDO::FETCH_ASSOC);
while ($row = $stmt->fetch()) {
var_dump($row);
}
$stmt->closeCursor();
print '';
Expected result:
active_persistent_connections and pconnect_success should be accurate to
match what you are really doing. Also the command line 'netstat -anp|grep
:3306|grep httpd|grep ESTABLISHED" should show a limit at some point on the
number of connections that are persistent, or they should get re-used.
Actual result:
--
There are a lot of unaccounted for idle ESTABLISHED in the netstat command,
for connections from httpd to mysql when mysqlnd indicates there are not
that many.
--
Edit bug report at https://bugs.php.net/bug.php?id=64549&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64549&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64549&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64549&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64549&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64549&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64549&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64549&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64549&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64549&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64549&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64549&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64549&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64549&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64549&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64549&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64549&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64549&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64549&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64549&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64549&r=mysqlcfg
[PHP-BUG] Bug #64548 [NEW]: Last Month (feb/march issue)
From: timothymarois at gmail dot com
Operating system:
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:Last Month (feb/march issue)
Description:
At the moment, because today is March 29th, my script using
date("F Y",strtotime('-1 Month')) or date("F Y",strtotime('Last Month'))
Shows March 2013 (a few days ago it showed February 2013) I believe this is
due
to
feb's short days. I did some testing to it, if I where to do
date("F Y",strtotime('-2 Month')) the output is January 2013, thats current
to
the
current date.
This would be a bug due to php's capabilities in resolving actual calendar
days.
I've seen postings that "this is not a bug" but it is, you can't have a
script
designed to give calendar day results, and have it given the wrong results
out.
Its incorrect and needs to be resolves. PHP is the software, and the
software
should be patched to give the current calendar days.
Test script:
---
date("F Y",strtotime('Last Month'))
Expected result:
February 2013
Actual result:
--
March 2013
--
Edit bug report at https://bugs.php.net/bug.php?id=64548&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64548&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64548&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64548&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64548&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64548&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64548&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64548&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64548&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64548&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64548&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64548&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64548&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64548&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64548&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64548&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64548&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64548&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64548&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64548&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64548&r=mysqlcfg
Bug #64544 [Opn->Csd]: Valgrind warnings after using putenv (due to processtitle)
Edit report at https://bugs.php.net/bug.php?id=64544&edit=1 ID: 64544 Updated by: ke...@php.net Reported by:ni...@php.net Summary:Valgrind warnings after using putenv (due to processtitle) -Status: Open +Status: Closed Type: Bug Package:CGI/CLI related PHP Version:5.5.0beta1 -Assigned To: +Assigned To:keyur Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fix committed to git: https://github.com/php/php- src/commit/5bf6323e5114646357197a343d202c0f1b8450a1 Thanks for finding this! Previous Comments: [2013-03-29 03:52:24] larue...@php.net The following patch has been added/updated: Patch Name: bug64544.patch Revision: 1364529144 URL: https://bugs.php.net/patch-display.php?bug=64544&patch=bug64544.patch&revision=1364529144 [2013-03-29 03:11:48] larue...@php.net The following patch has been added/updated: Patch Name: bug64544.patch Revision: 1364526708 URL: https://bugs.php.net/patch-display.php?bug=64544&patch=bug64544.patch&revision=1364526708 [2013-03-28 17:07:41] ni...@php.net Description: Due to the changes introduced by https://wiki.php.net/rfc/cli_process_title running https://bugs.php.net/bug.php?id=64544&edit=1
Bug #63010 [Opn->Csd]: libtool: link: cannot find the library `/lib/libgcrypt.la'
Edit report at https://bugs.php.net/bug.php?id=63010&edit=1 ID: 63010 User updated by:showerheadsuk at hotmail dot com Reported by:showerheadsuk at hotmail dot com Summary:libtool: link: cannot find the library `/lib/libgcrypt.la' -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Ubuntu 12.04 LTS PHP Version:5.4.6 Block user comment: N Private report: N New Comment: Issue was that libxslt had been compiled pointing at a libgcrypt that no longer existed. Recompiling libxslt with the new location of libgcrypt solved the issue. (So not a PHP bug) Previous Comments: [2012-09-04 12:55:18] showerheadsuk at hotmail dot com Description: When I try to make or make test php, compile fails with the error: libtool: link: cannot find the library `/lib/libgcrypt.la' or unhandled argument `/lib/libgcrypt.la' make: *** [sapi/cli/php] Error 1 I have libgcrypt installed in a non-standard location, but I am specifying the location with the LDFLAGS and CPPFLAGS in configure. It is still looking in /lib for the files though, I don't why? Test script: --- LDFLAGS=-L$HOME/apps/libgcrypt/lib CPPFLAGS=-I$HOME/apps/libgcrypt/include ./configure --prefix=$HOME/apps/$PHP \ --enable-mbstring \ --enable-zip \ --enable-fpm \ --enable-ftp \ --with-openssl=$HOME/apps/openssl \ --with-openssl-dir=$HOME/apps/openssl \ --with-jpeg-dir=$HOME/apps/libjpeg-turbo \ --with-gd \ --with-freetype-dir=/usr \ --with-gettext \ --with-xmlrpc \ --with-icu-dir=$HOME/apps/icu4c \ --enable-intl \ --with-pdo-mysql=mysqlnd \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-zlib-dir=/usr \ --with-kerberos=/usr \ --with-png-dir=/usr \ --with-ldap=$HOME/apps/openldap \ --with-curl=$HOME/apps/curl \ --with-mcrypt=$HOME/apps/libmcrypt \ --with-mhash=$HOME/apps/mhash \ --with-tidy=$HOME/apps/tidy \ --with-libxml-dir=$HOME/apps/libxml2 \ --with-iconv-dir=$HOME/apps/libiconv \ --with-xsl=$HOME/apps/libxslt Expected result: Successful compile Actual result: -- libtool: link: cannot find the library `/lib/libgcrypt.la' or unhandled argument `/lib/libgcrypt.la' make: *** [sapi/cli/php] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63010&edit=1
