Bug #60052 [Com]: Integer returned as a 64bit integer on X64_86

2013-10-07 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=60052edit=1

 ID: 60052
 Comment by: mar...@php.net
 Reported by:m dot vanduren at jonker dot nl
 Summary:Integer returned as a 64bit integer on X64_86
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   All (linux tested)
 PHP Version:5.3.8
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

I will recheck and apply it (the patch)


Previous Comments:

[2013-09-25 18:22:14] slavb18 at gmail dot com

why this patch only partially accepted? still not working on x86-64
$q=select * FROM RDB\$DATABASE;
$q=execute block
returns (
rI integer)
as
begin
rI= -1;
suspend;
end;
$res=$pdo-dbExecute($q);
print_r($res-fetch());

outputs
Array
(
[RI] = 4294967295
[0] = 4294967295
)
istead of
Array
(
[RI] = -1
[0] = -1
)


[2012-04-02 14:04:37] mar...@php.net

LL_MASK it should be already be l see the php_pdo_firebird_int.h:# define 
LL_MASK l

So in the in the slprintf 
slprintf(*ptr, CHAR_BUF_LEN, % LL_MASK d, *(ISC_INT64*)var-sqldata);
should be replaced with 

slprintf(*ptr, CHAR_BUF_LEN, % l d, *(ISC_INT64*)var-sqldata);

I will check and create a test for 5.3.x


[2011-10-13 13:01:36] m dot vanduren at jonker dot nl

Description:

Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit 
integer.
In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated 
as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't 
honor the bit-sign in a value and INT64 doesn't return anything.

This patch should fix this value for x86_64 systems while leaving x86 systems 
unchanged.

Test script:
---
any firebirdSQL database with a integer field containing a negative value.
retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it 
to the screen.

Expected result:

negative values with integer and should be returned as a negative number.

Actual result:
--
negative values are returned as their unsigned counterpart.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60052edit=1


Req #63356 [Com]: Add support for native php data types returned from Firebird PDO select queries

2013-02-07 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=63356edit=1

 ID: 63356
 Comment by: mar...@php.net
 Reported by:james at kenjim dot com
 Summary:Add support for native php data types returned from
 Firebird PDO select queries
 Status: Assigned
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   All
 PHP Version:5.4Git-2012-10-25 (Git)
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

Could you split the patch for each bug the ones that you mentioned at the end

Also i will ask about the patching of /ext/pdo/pdo_stmt.c , i'm not sure what 
is 
the right way so i better ask on the list first


Previous Comments:

[2012-10-25 08:11:17] james at kenjim dot com

Description:

The data returned from a $rs-fetch() should use native data types when 
applicable.  Currently all data is turned into strings.  Using native data 
types will not only provide a way for the user to easily check the data type.  
It should also give a performance enhancement since everything does not need to 
be turned into a string.  Some other database adapters already provide this 
ability.

I have included a patch to add this functionality however I did have to modify 
/ext/pdo/pdo_stmt.c due to the way it was handling returning of zval's.  It was 
expecting a ***zval when it really should of been a **zval.  Due to this 
excessive pointer requirement any other pdo database driver that returns zval's 
will need to be fixed.  I included in my patch a possible fix for the mysqlng 
pdo driver since I believe this is the only driver that uses it.  I say 
possible fix because I have not tested the mysqlng support part of it.  The 
patch also includes my patch for Bug #61183 - Firebird PDO memory corruption.  
It should also fix Bug #60052 - Integer returned as a 64bit integer on X64_86.  
It also fixes the patch that was improperly applied in Bug #47415 - 
PDO_Firebird segfaults when passing lowercased column name to bindColumn().







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63356edit=1


[PHP-BUG] Req #63105 [NEW]: Default transanction isolation level in PHP for Firebird in php.ini

2012-09-18 Thread mar...@php.net
From: mariuz
Operating system: All
PHP version:  Irrelevant
Package:  InterBase related
Bug Type: Feature/Change Request
Bug description:Default transanction isolation level in PHP for Firebird in 
php.ini

Description:

 If you start a new transaction (or if one is started internally, where you

cannot change the isolation level) where you don’t explicitly specify
isolation 
level the IBASE_DEFAULT is used. But this is 
IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT. This is read-write wait
transaction in 
concurrency mode. This mode is most restrictive, nothing close to read
committed. 
And to make it worse, there’s no way to change this default value in
runtime. You 
can only do it recompiling sources, nothing to be viable in most cases.

http://blog.cincura.net/233007-default-transanction-isolation-level-in-php-for-
firebird/


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63105edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63105r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63105r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=63105r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63105r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=63105r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63105r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=63105r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=63105r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=63105r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=63105r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=63105r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=63105r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=63105r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63105r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=63105r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63105r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=63105r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=63105r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=63105r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=63105r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=63105r=mysqlcfg



Req #63105 [Com]: Default transanction isolation level in PHP for Firebird in php.ini

2012-09-18 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=63105edit=1

 ID: 63105
 Comment by: mar...@php.net
 Reported by:mar...@php.net
 Summary:Default transanction isolation level in PHP for
 Firebird in php.ini
 Status: Open
 Type:   Feature/Change Request
 Package:InterBase related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Discussion on firebird php list 


http://tech.groups.yahoo.com/group/firebird-php/message/3758


Previous Comments:

[2012-09-18 07:18:47] mar...@php.net

Description:

 If you start a new transaction (or if one is started internally, where you 
cannot change the isolation level) where you don’t explicitly specify 
isolation 
level the IBASE_DEFAULT is used. But this is 
IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT. This is read-write wait transaction 
in 
concurrency mode. This mode is most restrictive, nothing close to read 
committed. 
And to make it worse, there’s no way to change this default value in runtime. 
You 
can only do it recompiling sources, nothing to be viable in most cases.

http://blog.cincura.net/233007-default-transanction-isolation-level-in-php-for-
firebird/







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63105edit=1


Bug #61939 [Com]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

2012-07-06 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=61939edit=1

 ID: 61939
 Comment by: mar...@php.net
 Reported by:sim-mail at list dot ru
 Summary:PDO_FIREBIRD incorrect result of query for
 NUMERIC(x, y) type in 1 dialect
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Windows 7 32bit
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

Currently it is possible to create databases in Dialect 1 and 3 only, however 
it 
is recommended that you use Dialect 3 exclusively, since Dialect 1 will 
eventually be deprecated.


Previous Comments:

[2012-06-26 15:50:14] manubing at gmail dot com

Also affected on macosx using PHP 5.3.10 and debian lenny with PHP 
5.2.6-1+lenny16.

Something odd: incorrect results are the same for a column for all rows fetched:
using the previous example:

public 'COST' = string '1.00' -- Error

All rows fetched will have 'COST' set to '1.00' (even if actual values differs)


Running again the query will give another (eg: '600.00') incorrect value, 
the same on all rows again.


[2012-05-04 14:53:01] sim-mail at list dot ru

only 1 dialect


[2012-05-04 14:50:22] sim-mail at list dot ru

Description:

PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y) type

?php
$sql = 'select * from price';
$dbh = new 
PDO('firebird:dbname=localhost:d:\interbasedata\test.fdb;charset=win1251', 
'sysdba', 'masterkey');
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sth = $dbh-prepare($sql);
$sth-execute();
$obj = $sth-fetch();
var_dump($obj);
$sth = null;
?

Script print 

object(stdClass)[3]
  public 'ID' = string '1' (length=1)
  public 'NAME' = string 'my price' (length=8)
  public 'COST' = string '1.00' (length=4) -- Error hear (correct result 
12.34)

Test script:
---
Sql script for create database

SET SQL DIALECT 1;
SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:D:\interbasedata\test.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET WIN1251 COLLATION WIN1251;

CREATE TABLE PRICE (
IDINTEGER NOT NULL,
NAME  VARCHAR(10),
COST  NUMERIC(15,2)
);

INSERT INTO PRICE (ID, NAME, COST) VALUES (1, 'my price', 12.34);

COMMIT WORK;

ALTER TABLE PRICE ADD CONSTRAINT PK_PRICE PRIMARY KEY (ID);







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61939edit=1


Bug #60052 [Com]: Integer returned as a 64bit integer on X64_86

2012-04-02 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=60052edit=1

 ID: 60052
 Comment by: mar...@php.net
 Reported by:m dot vanduren at jonker dot nl
 Summary:Integer returned as a 64bit integer on X64_86
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   All (linux tested)
 PHP Version:5.3.8
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

LL_MASK it should be already be l see the php_pdo_firebird_int.h:# define 
LL_MASK l

So in the in the slprintf 
slprintf(*ptr, CHAR_BUF_LEN, % LL_MASK d, *(ISC_INT64*)var-sqldata);
should be replaced with 

slprintf(*ptr, CHAR_BUF_LEN, % l d, *(ISC_INT64*)var-sqldata);

I will check and create a test for 5.3.x


Previous Comments:

[2011-10-13 13:01:36] m dot vanduren at jonker dot nl

Description:

Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit 
integer.
In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated 
as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't 
honor the bit-sign in a value and INT64 doesn't return anything.

This patch should fix this value for x86_64 systems while leaving x86 systems 
unchanged.

Test script:
---
any firebirdSQL database with a integer field containing a negative value.
retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it 
to the screen.

Expected result:

negative values with integer and should be returned as a negative number.

Actual result:
--
negative values are returned as their unsigned counterpart.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60052edit=1


Req #26379 [Com]: ext/interbase: must be linked with -lcrypt under FreeBSD

2012-01-20 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=26379edit=1

 ID: 26379
 Comment by: mar...@php.net
 Reported by:nicol at aokp dot ru
 Summary:ext/interbase: must be linked with -lcrypt under
 FreeBSD
 Status: Feedback
 Type:   Feature/Change Request
 Package:InterBase related
 Operating System:   FreeBSD 4.9
 PHP Version:4.3.4
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

tested with bsd 9.0 php 5.3.9 

and all seems to be fine now 
./configure --with-interbase  works out of the box (tar)


Previous Comments:

[2011-09-12 09:51:45] mar...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




[2011-07-19 16:29:58] mar...@php.net

To do 
test ./configure on newest freebsd stable 8.x

but i don't think this bug can be reproduced anymore (firebird doesn't use 
lcrypt 
or the extension for it)


[2003-11-24 03:11:13] nicol at aokp dot ru

Description:

php 4.3.4/5.0.0.Beta2 same bug
configure fails when detecting Interbase(Firebird) under FreeBSD (undefined 
reference to 'crypt'), because configure checks crypt() in -lcrypt after 
checking isc_detach_database() in -lgds and test program was linke without 
-lcrypt.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=26379edit=1


Bug #60802 [Com]: ibase_trans() gives segfault when passing params

2012-01-19 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=60802edit=1

 ID: 60802
 Comment by: mar...@php.net
 Reported by:lars dot westermann at privat dot dk
 Summary:ibase_trans() gives segfault when passing params
 Status: Assigned
 Type:   Bug
 Package:InterBase related
 Operating System:   Linux
 PHP Version:5.3.9
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

I saw that difference from 5.4 and now i know what was :)
I will merge back patch and 5.3 will look the same like in 5.2 , and 5.4


Previous Comments:

[2012-01-19 22:25:54] mar...@php.net

Automatic comment from SVN on behalf of mariuz
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=322477
Log: Fix #60802 ibase_trans() gives segfault when passing params (The amp;argn 
passed to zend_parse_parameters shall be a pointer to an integer, not to an 
unsigned short.)


[2012-01-19 09:48:11] lars dot westermann at privat dot dk

Description:

The ibase_trans() function segfaults when you pass connection-id and/or mode to 
the function.

After comparing both 5.2.x version of interbase.c and 5.3.x version, I found 
the solution:

# diff interbase.c interbase-fix.c
1128c1128,1129
   unsigned short i, argn, link_cnt = 0, tpb_len = 0;
---
   unsigned short i, link_cnt = 0, tpb_len = 0;
   int argn;

The argn passed to zend_parse_parameters shall be a pointer to an integer, not 
to an unsigned short.

Test script:
---
$DB = ibase_pconnect($DB_name, $DB_user, $DB_pw );
$TR = ibase_trans($DB);

is enough to trigger the error.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60802edit=1


Req #54150 [Com]: Enhance phpinfo output for pdo_firebird

2011-12-11 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=54150edit=1

 ID: 54150
 Comment by: mar...@php.net
 Reported by:preeves at ibphoenix dot com
 Summary:Enhance phpinfo output for pdo_firebird
 Status: Assigned
 Type:   Feature/Change Request
 Package:PDO related
 PHP Version:5.3.5
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

I will check it and i will apply it to 5.3,5.4 and trunk


Previous Comments:

[2011-03-03 16:10:05] preeves at ibphoenix dot com

Description:

The phpinfo output for the pdo_firebird driver is a bit sparse. I've lifted the
code from the interbase driver so that at least we will now output version info.
It is not a lot, but at least it makes the driver seem a little more loved.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54150edit=1


Req #8897 [Com]: Significant portions of the InterBase API have no PHP representation.

2011-12-11 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=8897edit=1

 ID: 8897
 Comment by: mar...@php.net
 Reported by:awjunkmail at anduin dot com
 Summary:Significant portions of the InterBase API have no
 PHP representation.
 Status: Open
 Type:   Feature/Change Request
 Package:InterBase related
 Operating System:   All
 PHP Version:4.0.3pl1
 Block user comment: N
 Private report: N

 New Comment:

Ok then i will close it the bug  is for php4 only


Previous Comments:

[2011-09-11 15:59:52] lester at lsces dot co dot uk

This is a very old situation. PHP5 interbase driver supports everything listed, 
but was never backported to PHP4, so suggest this is just closed?


[2001-01-25 04:30:40] awjunkmail at anduin dot com

InterBase has four functions for executing SQL commands. The current PHP 
wrappers use one: isc_dsql_execute.

If you had to choose which of the prepared execute functions to wrap 
isc_dsql_execute2() would have been a better choice. This would have allowed 
things like EXECUTE PROCEDURE in addition to all the functionality of 
isc_dsql_execute(). It would also remove the need to use SELECT to run a 
procedure.

More importantly is that isc_dsql_execute_immediate() and 
isc_dsql_exec_immed2() are not exposed in any form.

Along the same lines functions for managing users would be nice as well 
(isc_add/delete/modify_user).






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=8897edit=1


Bug #48877 [Com]: bindValue and bindParam do not work for PDO Firebird

2011-12-10 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=48877edit=1

 ID: 48877
 Comment by: mar...@php.net
 Reported by:siegmar at siegmar dot com dot br
 Summary:bindValue and bindParam do not work for PDO
 Firebird
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Windows
 PHP Version:5.2.10
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

tested and result was 2


cat test.php 
?php
$connection = new 
PDO('firebird:dbname=localhost:/var/lib/firebird/2.5/data/employee.fdb', 
'SYSDBA', 'masterkey');

$value = '2';

$command = $connection-prepare('SELECT EMP_NO FROM EMPLOYEE WHERE EMP_NO = 
:empno');
$command-bindParam(':empno', $value, PDO::PARAM_STR); // does not work
$command-bindValue(':empno', $value, PDO::PARAM_STR); // does not work

#$command = $connection-prepare('SELECT EMP_NO FROM EMPLOYEE WHERE EMP_NO = 
?');
#$command-bindParam('1', $value, PDO::PARAM_STR); // works
//$command-bindValue('1', $value, PDO::PARAM_STR); // works

$command-execute();
$dataset = $command-fetchAll();
foreach($dataset as $record)
  echo $record[0] . br /;
?


Previous Comments:

[2011-12-10 22:20:51] mar...@php.net

This bug has been fixed in SVN.

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.




[2011-12-10 22:09:41] mar...@php.net

Automatic comment from SVN on behalf of mariuz
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=320856
Log: bug fixed #48877 - bindValue and bindParam do not work for PDO Firebird


[2011-12-10 22:08:20] mar...@php.net

Automatic comment from SVN on behalf of mariuz
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=320855
Log: bug fixed #48877 - bindValue and bindParam do not work for PDO Firebird


[2011-12-10 22:04:04] mar...@php.net

Automatic comment from SVN on behalf of mariuz
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=320854
Log: bug fixed #48877 - bindValue and bindParam do not work for PDO Firebird


[2010-07-04 05:14:44] ssufficool at gmail dot com

Try changing the :empno to just empno in bind* it is not expected or needed:

$command = $connection-prepare('SELECT EMP_NO FROM EMPLOYEE WHERE EMP_NO = 
:empno');
$command-bindParam('empno', $value, PDO::PARAM_STR); // does not work
$command-bindValue('empno', $value, PDO::PARAM_STR); // does not work




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=48877


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=48877edit=1


Req #55659 [Com]: Correcting phpt test files for current configurations

2011-09-12 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=55659edit=1

 ID: 55659
 Comment by: mar...@php.net
 Reported by:lester at lsces dot co dot uk
 Summary:Correcting phpt test files for current
 configurations
 Status: Open
 Type:   Feature/Change Request
 Package:InterBase related
 Operating System:   Linux ( should be OS agnostic )
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

fixed in 5.4 and trunk


Previous Comments:

[2011-09-12 09:36:22] mar...@php.net

Automatic comment from SVN on behalf of mariuz
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316515
Log: fixes #55659 also the 006 firebird test


[2011-09-09 20:32:24] lester at lsces dot co dot uk

Description:

Test 003 result default field names have changed over time. Not sure how far 
bake the change goes database version wise.
Test 006 is demonstrating how rounding of integers works rather than flagging 
an real error. 7.5 should always round up to 8, so that should be expected in 
the result set. 

Test script:
---
Patch is for the test script ...







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55659edit=1


Req #26379 [Com]: ext/interbase: must be linked with -lcrypt under FreeBSD

2011-07-19 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=26379edit=1

 ID: 26379
 Comment by: mar...@php.net
 Reported by:nicol at aokp dot ru
 Summary:ext/interbase: must be linked with -lcrypt under
 FreeBSD
 Status: Assigned
 Type:   Feature/Change Request
 Package:InterBase related
 Operating System:   FreeBSD 4.9
 PHP Version:4.3.4
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

To do 
test ./configure on newest freebsd stable 8.x

but i don't think this bug can be reproduced anymore (firebird doesn't use 
lcrypt 
or the extension for it)


Previous Comments:

[2003-11-24 03:11:13] nicol at aokp dot ru

Description:

php 4.3.4/5.0.0.Beta2 same bug
configure fails when detecting Interbase(Firebird) under FreeBSD (undefined 
reference to 'crypt'), because configure checks crypt() in -lcrypt after 
checking isc_detach_database() in -lgds and test program was linke without 
-lcrypt.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=26379edit=1