#30995 [NEW]: Net-SNMP5.2 causes compile failure in ext/snmp/snmp.c

2004-12-06 Thread robbat2 at gentoo dot org 
From: robbat2 at gentoo dot org
Operating system: Linux
PHP version:  Irrelevant
PHP Bug Type: Compile Failure
Bug description:  Net-SNMP5.2 causes compile failure in ext/snmp/snmp.c

Description:

(Apologies if this is a dupe, my ISP is having some issues tonight)

PHP4* and PHP5* (including the latest releases AND CVS checkouts) do NOT
compile on a system with Net-SNMP 5.2*.

This is because Net-SNMP has become more standards-compliant and got rid
of some AES192/AES256 stuff they had.

To conform with RFC3826, these are the changes they made:
http://cvs.sourceforge.net/viewcvs.py/net-snmp/net-snmp/snmplib/snmpusm.c?r1=5.10r2=5.11only_with_tag=MAIN
http://cvs.sourceforge.net/viewcvs.py/net-snmp/net-snmp/snmplib/snmpv3.c?r1=5.9r2=5.10only_with_tag=MAIN
http://www.ietf.org/rfc/rfc3826.txt

Note the removal of the following symbols:
usmAES192PrivProtocol
usmAES256PrivProtocol

PHP uses the above 2 symbols.

I've got a patch for ext/snmp/snmp.c to make PHP compile properly for all
versions of net-snmp now.

Patch for PHP4:
http://dev.gentoo.org/~robbat2/php4-netsnmp52-aes.diff
Patch for PHP5:
http://dev.gentoo.org/~robbat2/php5-netsnmp52-aes.diff

Reproduce code:
---
Install NET-SNMP-5.2*
configure with SNMP turned on
try to build.

Expected result:

should compile fine.

Actual result:
--
/bin/sh /var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/libtool --silent
--preserve-dup-deps --mode=compile gcc
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/sqlite/libsqlite/src
-Iext/sqlite/ -I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/sqlite/
-DPHP_ATOM_INC -I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/include
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/main
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/Zend -I/usr/include/libxml2
-I/usr/include/freetype2 -I/usr/include/imap
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/mbstring/oniguruma
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/mbstring/libmbfl
-I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/mbstring/libmbfl/mbfl
-I/usr/include/pspell  -I/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/TSRM
 -O3 -march=athlon-xp -fomit-frame-pointer -pipe  -prefer-pic -c
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/sqlite/sqlite.c -o
ext/sqlite/sqlite.lo
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c: In function
`netsnmp_session_set_sec_protocol':
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:795: error:
`usmAES192PrivProtocol' undeclared (first use in this function)
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:795: error:
(Each undeclared identifier is reported only once
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:795: error:
for each function it appears in.)
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:799: error:
`usmAES256PrivProtocol' undeclared (first use in this function)
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c: In function
`netsnmp_session_gen_auth_key':
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:822: warning:
initialization discards qualifiers from pointer target type
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c: In function
`netsnmp_session_gen_sec_key':
/var/tmp/portage/php-5.0.2-r1/work/php-5.0.2/ext/snmp/snmp.c:851: warning:
initialization discards qualifiers from pointer target type
make: *** [ext/snmp/snmp.lo] Error 1
make: *** Waiting for unfinished jobs


-- 
Edit bug report at http://bugs.php.net/?id=30995edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30995r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=30995r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=30995r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30995r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30995r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30995r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30995r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30995r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30995r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30995r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=30995r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=30995r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30995r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30995r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30995r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30995r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30995r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30995r=float
MySQL

#30637 [Com]: compile with pear error

2004-11-01 Thread robbat2 at gentoo dot org 
 ID:   30637
 Comment by:   robbat2 at gentoo dot org
 Reported By:  arthur at mir5 dot homeip dot net
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: (Slackware) linux-2.4.25
 PHP Version:  5.0.2
 New Comment:

The PHP test script that this is reproducable for is depressingly
small...
?php
?
the extensions directory is totally empty...

running:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -m -n
will give correct output one time out of ten, and fail dismally the
other times (leaving a corefile that backtraces to the output I gave in
my other bug).

Included here again for good measure:
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
242 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(gdb) bt
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
#1  0x08165192 in zend_hash_destroy (ht=0x81ba8cc) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c:563
#2  0x0815483d in shutdown_executor () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_execute_API.c:186
#3  0x0815ec10 in zend_deactivate () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend.c:667
#4  0x0812914a in php_request_shutdown (dummy=0x0) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/main/main.c:996
#5  0x08177c0b in main (argc=3, argv=0xbfffeda4) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php_cli.c:873


The most output it does give me is:

[PHP Modules]
ctype
domxml
overload
pcre
posix
session
standard
tokenizer
xml
zlib

[Zend Modules]



Previous Comments:


[2004-11-01 09:19:17] [EMAIL PROTECTED]

Great, I can not reproduce this at all btw.
Can you also please use Edit Submission instead of Add Comment when
replying to your own bugreports?



[2004-11-01 09:10:09] robbat2 at gentoo dot org

As I noted, the php.ini is totally stock php.ini-dist, and the problem
still happens when there is no php.ini in the config-file directory.
There are definetly no extensions being loaded at all.

The exact failing command that is run by make install is:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml

Complete output:
[EMAIL PROTECTED] /var/tmp/portage/php-4.3.9/work/php-4.3.9 #
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml
Could not startup.
[Mon Nov  1 01:08:50 2004]  Script: 
'/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php'
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_ptr_stack.c(77) :
Block 0x081FD820 status:
Beginning:  Overrun (magic=0x08201868, expected=0x7312F8DC)
  End:  Unknown
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(547) :
ht=0x081ba8cc is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(673) :
ht=0x081ba9e8 is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(108) :
Bailed out without a bailout address!

I'll try to come up with something shorter than install-pear.php  that
will reproduce it.



[2004-11-01 08:22:13] [EMAIL PROTECTED]

Well, that backtrace doesn't really help without a short reproducing
script. Are you loading any extension and/or zend extensions?



[2004-11-01 08:02:18] robbat2 at gentoo dot org

Derick: If this is the same bug as I reported in bug 30639, despite
different major versions of the ZendEngine, then you can utilize the
backtrace I posted on that bug.



[2004-11-01 07:52:18] [EMAIL PROTECTED]

Please provide a backtrace as asked before.



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/30637

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

#30637 [Com]: compile with pear error

2004-11-01 Thread robbat2 at gentoo dot org 
 ID:   30637
 Comment by:   robbat2 at gentoo dot org
 Reported By:  arthur at mir5 dot homeip dot net
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: (Slackware) linux-2.4.25
 PHP Version:  5.0.2
 New Comment:

I have to use add comment, as this here isn't my bug report, 30639 is
my bug.


Previous Comments:


[2004-11-01 09:20:12] robbat2 at gentoo dot org

The PHP test script that this is reproducable for is depressingly
small...
?php
?
the extensions directory is totally empty...

running:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -m -n
will give correct output one time out of ten, and fail dismally the
other times (leaving a corefile that backtraces to the output I gave in
my other bug).

Included here again for good measure:
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
242 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(gdb) bt
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
#1  0x08165192 in zend_hash_destroy (ht=0x81ba8cc) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c:563
#2  0x0815483d in shutdown_executor () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_execute_API.c:186
#3  0x0815ec10 in zend_deactivate () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend.c:667
#4  0x0812914a in php_request_shutdown (dummy=0x0) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/main/main.c:996
#5  0x08177c0b in main (argc=3, argv=0xbfffeda4) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php_cli.c:873


The most output it does give me is:

[PHP Modules]
ctype
domxml
overload
pcre
posix
session
standard
tokenizer
xml
zlib

[Zend Modules]




[2004-11-01 09:19:17] [EMAIL PROTECTED]

Great, I can not reproduce this at all btw.
Can you also please use Edit Submission instead of Add Comment when
replying to your own bugreports?



[2004-11-01 09:10:09] robbat2 at gentoo dot org

As I noted, the php.ini is totally stock php.ini-dist, and the problem
still happens when there is no php.ini in the config-file directory.
There are definetly no extensions being loaded at all.

The exact failing command that is run by make install is:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml

Complete output:
[EMAIL PROTECTED] /var/tmp/portage/php-4.3.9/work/php-4.3.9 #
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml
Could not startup.
[Mon Nov  1 01:08:50 2004]  Script: 
'/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php'
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_ptr_stack.c(77) :
Block 0x081FD820 status:
Beginning:  Overrun (magic=0x08201868, expected=0x7312F8DC)
  End:  Unknown
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(547) :
ht=0x081ba8cc is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(673) :
ht=0x081ba9e8 is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(108) :
Bailed out without a bailout address!

I'll try to come up with something shorter than install-pear.php  that
will reproduce it.



[2004-11-01 08:22:13] [EMAIL PROTECTED]

Well, that backtrace doesn't really help without a short reproducing
script. Are you loading any extension and/or zend extensions?



[2004-11-01 08:02:18] robbat2 at gentoo dot org

Derick: If this is the same bug as I reported in bug 30639, despite
different major versions of the ZendEngine, then you can utilize the
backtrace I posted on that bug.



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/30637

-- 
Edit this bug report at http://bugs.php.net

#30637 [Com]: compile with pear error

2004-11-01 Thread robbat2 at gentoo dot org 
 ID:   30637
 Comment by:   robbat2 at gentoo dot org
 Reported By:  arthur at mir5 dot homeip dot net
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: (Slackware) linux-2.4.25
 PHP Version:  5.0.2
 New Comment:

valgrind output:
http://dev.gentoo.org/~robbat2/php-4.3.9-valgrind.trace


Previous Comments:


[2004-11-01 09:29:22] [EMAIL PROTECTED]

Can you run valgrind on this, like in:
valgrind php ./script-that-crashes.php

and put the output somewhere online?

Derick



[2004-11-01 09:21:34] robbat2 at gentoo dot org

I have to use add comment, as this here isn't my bug report, 30639 is
my bug.



[2004-11-01 09:20:12] robbat2 at gentoo dot org

The PHP test script that this is reproducable for is depressingly
small...
?php
?
the extensions directory is totally empty...

running:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -m -n
will give correct output one time out of ten, and fail dismally the
other times (leaving a corefile that backtraces to the output I gave in
my other bug).

Included here again for good measure:
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
242 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(gdb) bt
#0  0x0814d116 in _efree (ptr=0x0, __zend_filename=0x81a7cd8
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c,
__zend_lineno=563, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:242
#1  0x08165192 in zend_hash_destroy (ht=0x81ba8cc) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c:563
#2  0x0815483d in shutdown_executor () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_execute_API.c:186
#3  0x0815ec10 in zend_deactivate () at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend.c:667
#4  0x0812914a in php_request_shutdown (dummy=0x0) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/main/main.c:996
#5  0x08177c0b in main (argc=3, argv=0xbfffeda4) at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php_cli.c:873


The most output it does give me is:

[PHP Modules]
ctype
domxml
overload
pcre
posix
session
standard
tokenizer
xml
zlib

[Zend Modules]




[2004-11-01 09:19:17] [EMAIL PROTECTED]

Great, I can not reproduce this at all btw.
Can you also please use Edit Submission instead of Add Comment when
replying to your own bugreports?



[2004-11-01 09:10:09] robbat2 at gentoo dot org

As I noted, the php.ini is totally stock php.ini-dist, and the problem
still happens when there is no php.ini in the config-file directory.
There are definetly no extensions being loaded at all.

The exact failing command that is run by make install is:
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml

Complete output:
[EMAIL PROTECTED] /var/tmp/portage/php-4.3.9/work/php-4.3.9 #
/var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php -n
-dshort_open_tag=0 -dsafe_mode=0
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php -d
/usr/lib/php -b /usr/bin
/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/package-*.xml
Could not startup.
[Mon Nov  1 01:08:50 2004]  Script: 
'/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php'
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_ptr_stack.c(77) :
Block 0x081FD820 status:
Beginning:  Overrun (magic=0x08201868, expected=0x7312F8DC)
  End:  Unknown
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(547) :
ht=0x081ba8cc is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(673) :
ht=0x081ba9e8 is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(108) :
Bailed out without a bailout address!

I'll try to come up with something shorter than install-pear.php  that
will reproduce it.



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/30637

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

#30637 [Com]: compile with pear error

2004-11-01 Thread robbat2 at gentoo dot org 
 ID:   30637
 Comment by:   robbat2 at gentoo dot org
 Reported By:  arthur at mir5 dot homeip dot net
 Status:   Open
 Bug Type: Compile Failure
 Operating System: (Slackware) linux-2.4.25
 PHP Version:  5.0.2
 New Comment:

after setting up php-4.3.9 on another machine today and having it work
perfectly fine, I tried something on a hunch - found that php-4.3.9
compiled and installed perfectly fine after a reboot, but then didn't
want to install properly after that, until I rebooted the machine
again.

I'm going to pursue other angles of what could be the problem.


Previous Comments:


[2004-11-01 22:36:53] arthur at mir5 dot homeip dot net

php-5.0.2/pear# valgrind -v --tool=memcheck php ./install-pear.php 
http://mir5.homeip.net:8080/bugs/valgrindcheck.txt



[2004-11-01 21:05:35] [EMAIL PROTECTED]

valgrind --tool=memcheck php ./script-that-crashes.php

should do it.



[2004-11-01 19:47:06] arthur at mir5 dot homeip dot net

please tell me exactly what you want me to run.
valgrind php ./install-pear.php
you must give it a tool= option.
also what flags should i include.



[2004-11-01 10:40:08] robbat2 at gentoo dot org

valgrind output:
http://dev.gentoo.org/~robbat2/php-4.3.9-valgrind.trace



[2004-11-01 09:29:22] [EMAIL PROTECTED]

Can you run valgrind on this, like in:
valgrind php ./script-that-crashes.php

and put the output somewhere online?

Derick



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/30637

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

#30639 [NEW]: segfault at Zend/zend_alloc.c:241

2004-10-31 Thread robbat2 at gentoo dot org 
From: robbat2 at gentoo dot org
Operating system: Gentoo Linux
PHP version:  4.3.9
PHP Bug Type: Reproducible crash
Bug description:  segfault at Zend/zend_alloc.c:241

Description:

During PHP install, the PHP cli binary crashes when doing the PEAR
install:

 Install php-4.3.9 into /var/tmp/portage/php-4.3.9/image/ category
dev-php
Installing PHP CLI binary:   
/var/tmp/portage/php-4.3.9/image//usr/bin/
Installing PHP CLI man page: 
/var/tmp/portage/php-4.3.9/image//usr/share/man/man1/
Installing PEAR environment: 
/var/tmp/portage/php-4.3.9/image//usr/lib/php/
make[1]: *** [install-pear-installer] Segmentation fault (core dumped)
make: *** [install-pear] Error 2


Reproduce code:
---
make INSTALL_ROOT=/var/tmp/portage/php-4.3.9/image/ install
install-modules install-programs

Exact configure line was: ./configure  --prefix=/usr
--host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--disable-cgi --enable-cli --with-ndbm=/usr --with-db4=/usr
--with-mcrypt=/usr --with-mhash=/usr --without-interbase --without-ming
--without-swf --without-sybase --with-gdbm=/usr --without-fdftk
--without-java --with-mcal=/usr --without-unixODBC --without-pgsql
--with-snmp=/usr --enable-ucd-snmp-hack --without-gmp --without-mssql
--with-pdflib=/usr --with-gd --enable-gd-native-ttf --with-png=/usr
--with-png-dir=/usr --with-jpeg=/usr --with-jpeg-dir=/usr --enable-exif
--with-tiff=/usr --with-tiff-dir=/usr --with-mysql=/usr
--with-mysql-sock=/var/run/mysqld/mysqld.sock --with-freetype-dir=/usr
--with-ttf=/usr --with-t1lib=/usr --without-gettext --without-qtdom
--with-pspell=/usr --with-openssl=/usr --with-imap=/usr --without-ldap
--with-dom=/usr --with-dom-xslt=/usr --with-dom-exslt=/usr
--without-kerberos --with-pam --disable-memory-limit --enable-ipv6
--without-yaz --disable-debug --with-curlwrappers --with-curl=/usr
--enable-dbx --with-imap-ssl --with-zlib=/usr --with-zlib-dir=/usr
--with-sablot=/usr --enable-xslt --with-xslt-sablot --with-xmlrpc
--enable-wddx --with-xml --enable-mbstring=all --enable-mbregex
--with-bz2=/usr --with-crack=/usr --with-cdb --enable-pcntl
--enable-bcmath --enable-calendar --enable-dbase --enable-filepro
--enable-ftp --with-mime-magic=/usr/share/misc/file/magic.mime
--enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg
--with-iconv --enable-shmop --enable-dio --enable-yp --with-readline=/usr
--with-ncurses=/usr --enable-inline-optimization --enable-track-vars
--enable-trans-sid --enable-versioning
--with-config-file-path=/etc/php/cli-php4

and CFLAGS were only '-g', but I can reproduce this with a very stripped
set of configure flags as well.

php.ini is the stock php.ini-dist.

Expected result:

PHP should install fine.

Actual result:
--
Backtrace from coredump:

#0  0x0824d605 in _efree (ptr=0x0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:241
241 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(gdb) bt
#0  0x0824d605 in _efree (ptr=0x0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_alloc.c:241
#1  0x082623a8 in zend_hash_destroy (ht=0x850762c)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c:563
#2  0x08253d62 in shutdown_executor ()
at
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_execute_API.c:186
#3  0x0825ceb5 in zend_deactivate ()
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend.c:667
#4  0x0822d07c in php_request_shutdown (dummy=0x0)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/main/main.c:996
#5  0x0827dd58 in main (argc=12, argv=0xbfffd5b4)
at /var/tmp/portage/php-4.3.9/work/php-4.3.9/sapi/cli/php_cli.c:873


-- 
Edit bug report at http://bugs.php.net/?id=30639edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30639r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30639r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30639r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30639r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30639r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30639r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30639r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30639r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30639r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30639r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30639r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30639r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30639r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30639r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30639r=dst
IIS

#30639 [Opn]: segfault at Zend/zend_alloc.c:241

2004-10-31 Thread robbat2 at gentoo dot org 
 ID:   30639
 User updated by:  robbat2 at gentoo dot org
 Reported By:  robbat2 at gentoo dot org
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux
 PHP Version:  4.3.9
 New Comment:

Some more output, configured with :
./configure --prefix=/usr --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --disable-cgi --enable-cli
--without-ndbm --without-db4 --without-mcrypt --without-mhash
--without-interbase --without-ming --without-swf --without-sybase
--without-gdbm --without-fdftk --without-java --without-mcal
--without-unixODBC --without-pgsql --without-snmp --without-gmp
--without-mssql --without-pdflib --without-gd --disable-gd-native-ttf
--without-png --without-jpeg --disable-exif --without-tiff
--without-mysql --without-freetype-dir --without-ttf --without-t1lib
--without-gettext --without-qtdom --without-pspell --without-openssl
--without-imap --without-ldap --with-dom=/usr --without-dom-xslt
--without-dom-exslt --without-kerberos --without-pam
--disable-memory-limit --disable-ipv6 --without-yaz
--without-curlwrappers --without-curl --disable-dbx --without-imap-ssl
--with-zlib --with-sablot=/usr --disable-xslt --without-xslt-sablot
--without-xmlrpc --disable-wddx --without-xml --disable-mbstring
--disable-mbregex --without-bz2 --without-crack --without-cdb
--disable-pcntl --disable-bcmath --disable-calendar --disable-dbase
--disable-filepro --disable-ftp --without-mime-magic --disable-sockets
--disable-sysvsem --disable-sysvshm --disable-sysvmsg --without-iconv
--disable-shmop --disable-dio --disable-yp --without-readline
--without-ncurses --disable-inline-optimization --enable-versioning
--with-config-file-path=/etc/php/cli-php4 --enable-debug

I get:
 Install php-4.3.9 into /var/tmp/portage/php-4.3.9/image/ category
dev-php
Installing PHP CLI binary:   
/var/tmp/portage/php-4.3.9/image//usr/bin/
Installing PHP CLI man page: 
/var/tmp/portage/php-4.3.9/image//usr/share/man/man1/
Installing PEAR environment: 
/var/tmp/portage/php-4.3.9/image//usr/lib/php/
Could not startup.
[Sun Oct 31 20:05:19 2004]  Script: 
'/var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/install-pear.php'
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_ptr_stack.c(77) :
Block 0x081FD808 status:
Beginning:  Overrun (magic=0x081FDDC8, expected=0x7312F8DC)
  End:  Unknown
---
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(547) :
ht=0x081ba8cc is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(762) :
ht=0x081bb7a0 is being destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(673) :
ht=0x081ba9e8 is already destroyed
/var/tmp/portage/php-4.3.9/work/php-4.3.9/Zend/zend_hash.c(108) :
Bailed out without a bailout address!
make[1]: *** [install-pear-installer] Error 255
make: *** [install-pear] Error 2

binutils:
GNU ld version 2.15.90.0.1.1 20040303

gcc:
Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info
--enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--with-system-zlib --enable-languages=c,c++,f77 --enable-threads=posix
--enable-long-long --disable-checking --disable-libunwind-exceptions
--enable-cstdio=stdio --enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3
--with-local-prefix=/usr/local --enable-shared --enable-nls
--without-included-gettext --disable-multilib --enable-__cxa_atexit
--enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2,
pie-8.7.6)


Previous Comments:


[2004-11-01 03:41:08] robbat2 at gentoo dot org

Description:

During PHP install, the PHP cli binary crashes when doing the PEAR
install:

 Install php-4.3.9 into /var/tmp/portage/php-4.3.9/image/ category
dev-php
Installing PHP CLI binary:   
/var/tmp/portage/php-4.3.9/image//usr/bin/
Installing PHP CLI man page: 
/var/tmp/portage/php-4.3.9/image//usr/share/man/man1/
Installing PEAR environment: 
/var/tmp/portage/php-4.3.9/image//usr/lib/php/
make[1]: *** [install-pear-installer] Segmentation fault (core dumped)
make: *** [install-pear] Error 2


Reproduce code:
---
make INSTALL_ROOT=/var/tmp/portage/php-4.3.9/image/ install
install-modules install-programs

Exact configure line was: ./configure  --prefix=/usr
--host=i686-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir

#26168 [NEW]: phpize changes don't check for execute status on shtool

2003-11-07 Thread robbat2 at gentoo dot org 
From: robbat2 at gentoo dot org
Operating system: Gentoo Linux
PHP version:  4.3.4
PHP Bug Type: *Compile Issues
Bug description:  phpize changes don't check for execute status on shtool

Description:

phpize as of 4.3.4 does NOT check that $builddir/build/shtool is
executable before it tries to run it.

Reproduce code:
---
1. unpack any source based php extension (I used turck-mmcache-2.4.6)
2. ensure that your /usr/lib/php/build/shtool does NOT have execute set.
3. in the new dir, run phpize.

Expected result:

should complete correctly.

phpize should set shtool to be executable before it tries to run it, or at
the very least it should check if it is executable.

Actual result:
--
you get this error:
/usr/bin/phpize: line 1:
/var/tmp/portage/turck-mmcache-2.4.6/work/turck-mmcache-2.4.6/build/shtool:
Permission denied
/usr/bin/phpize: line 61: -f: command not found

-- 
Edit bug report at http://bugs.php.net/?id=26168edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26168r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26168r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26168r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26168r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26168r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26168r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26168r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26168r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26168r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26168r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26168r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26168r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26168r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26168r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26168r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26168r=float

#26168 [Opn]: phpize changes don't check for execute status on shtool

2003-11-07 Thread robbat2 at gentoo dot org 
 ID:   26168
 User updated by:  robbat2 at gentoo dot org
 Reported By:  robbat2 at gentoo dot org
 Status:   Open
 Bug Type: *Compile Issues
 Operating System: Gentoo Linux
 PHP Version:  4.3.4
 New Comment:

Patch that fixes phpize:
--- php-4.3.4/./scripts/phpize.in.old   2003-11-07 14:20:41.0
-0800
+++ php-4.3.4/./scripts/phpize.in   2003-11-07 14:21:07.0
-0800
@@ -57,6 +57,7 @@
 aclocal || exit 1
 autoconf || exit 1
 autoheader || exit 1
+test -x $builddir/build/shtool || chmod +x $builddir/build/shtool
 libtoolize=`$builddir/build/shtool path glibtoolize libtoolize`
 $libtoolize -f -c || exit 1


Previous Comments:


[2003-11-07 17:09:08] robbat2 at gentoo dot org

Description:

phpize as of 4.3.4 does NOT check that $builddir/build/shtool is
executable before it tries to run it.

Reproduce code:
---
1. unpack any source based php extension (I used turck-mmcache-2.4.6)
2. ensure that your /usr/lib/php/build/shtool does NOT have execute
set.
3. in the new dir, run phpize.

Expected result:

should complete correctly.

phpize should set shtool to be executable before it tries to run it, or
at the very least it should check if it is executable.

Actual result:
--
you get this error:
/usr/bin/phpize: line 1:
/var/tmp/portage/turck-mmcache-2.4.6/work/turck-mmcache-2.4.6/build/shtool:
Permission denied
/usr/bin/phpize: line 61: -f: command not found





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

#26168 [Opn]: phpize changes don't check for execute status on shtool

2003-11-07 Thread robbat2 at gentoo dot org 
 ID:   26168
 User updated by:  robbat2 at gentoo dot org
 Reported By:  robbat2 at gentoo dot org
 Status:   Open
 Bug Type: *Compile Issues
 Operating System: Gentoo Linux
 PHP Version:  4.3.4
 New Comment:

i do realize that /usr/lib/build/* will have the execute bits set on
them if the install-build make target has been used, but the purpose of
this patch is to


Previous Comments:


[2003-11-07 17:13:55] robbat2 at gentoo dot org

Patch that fixes phpize:
--- php-4.3.4/./scripts/phpize.in.old   2003-11-07 14:20:41.0
-0800
+++ php-4.3.4/./scripts/phpize.in   2003-11-07 14:21:07.0
-0800
@@ -57,6 +57,7 @@
 aclocal || exit 1
 autoconf || exit 1
 autoheader || exit 1
+test -x $builddir/build/shtool || chmod +x $builddir/build/shtool
 libtoolize=`$builddir/build/shtool path glibtoolize libtoolize`
 $libtoolize -f -c || exit 1



[2003-11-07 17:09:08] robbat2 at gentoo dot org

Description:

phpize as of 4.3.4 does NOT check that $builddir/build/shtool is
executable before it tries to run it.

Reproduce code:
---
1. unpack any source based php extension (I used turck-mmcache-2.4.6)
2. ensure that your /usr/lib/php/build/shtool does NOT have execute
set.
3. in the new dir, run phpize.

Expected result:

should complete correctly.

phpize should set shtool to be executable before it tries to run it, or
at the very least it should check if it is executable.

Actual result:
--
you get this error:
/usr/bin/phpize: line 1:
/var/tmp/portage/turck-mmcache-2.4.6/work/turck-mmcache-2.4.6/build/shtool:
Permission denied
/usr/bin/phpize: line 61: -f: command not found





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

#24141 [Fbk-Opn]: Massive configure script failures when LDAP is linked against kerberos.

2003-06-13 Thread robbat2 at gentoo dot org 
 ID:   24141
 User updated by:  robbat2 at gentoo dot org
 Reported By:  robbat2 at gentoo dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Gentoo Linux
 PHP Version:  4.3.2
 New Comment:

Hi Derick, a response.

As for the part of not finding the libkrb4.so.2, it turned out that the
user unmerged it without heed to that was linked against it.

However I still that that the configure script should have failed MUCH
earlier to make this failure easier to catch and not result in totally
erroroneus error messages.


Previous Comments:


[2003-06-12 03:01:25] [EMAIL PROTECTED]

Where is libkrb4.so.2 on your system, and is it in the paths
described in /etc/ld.so.conf ? And did you run ldconfig after
installing that ldap?



[2003-06-12 01:49:07] robbat2 at gentoo dot org

Description:

On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.

When that starts, it gives incorrect errors until it hits some check
that causes the configure script to bail out.

This results in a VERY incorrect error message being given by the
configure script.

This is similar to bug item #4133, but only a workaround was provided
for that bug, and not a proper fix.

I think in this case, putting the kerberos checks together with the
ldap stuff might solve the problem, but I'm not a configure guru.

Expected result:

Two things:
Firstly, there needs to be some form of checks against the libraries
that are added to the LIBS list so that the system catches ALL of the
extra libraries they are linked against.

Secondly, the configure script SHOULD fail sooner after errors, and
give more intelligable answers.
It should have failed right after the initial error that linking
against LDAP gave.

Actual result:
--
You can see the entire config.log file and more details at our
bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=22635

snippet from config.log when it first fails:
 CUT 
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe  -L/usr/lib 
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl  -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe  -L/usr/lib 
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt
-lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm
-ldl -lnsl  -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
 CUT 

Here is where it finally fails and gives up:
 CUT 
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe  -I/usr/include
-L/usr/lib  conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng
-ljpeg -lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt
-lpam -lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack
-lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl -lnsl  -lcurl -lz -lssl
-lcrypto -ldl -lz -lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt
15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try
using -rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h

#include stdlib.h
#include sablot.h

int main ()
{
double version;
version = atof(SAB_VERSION);

if (version = 0.96) {
exit(0);
}
exit(255);
}
 CUT 

The error that the above failure throws. Totally incorrect about the
problem of course.
 CUT 
checking for Sablotron version... configure: error: Sablotron version
0.96 or
greater required.
 CUT 





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

#24141 [NEW]: Massive configure script failures when LDAP is linked against kerberos.

2003-06-12 Thread robbat2 at gentoo dot org 
From: robbat2 at gentoo dot org
Operating system: Gentoo Linux
PHP version:  4.3.2
PHP Bug Type: Compile Failure
Bug description:  Massive configure script failures when LDAP is linked against 
kerberos.

Description:

On a system that has OpenLDAP installed, and dynamically linked against
kerberos, the configure script starts massively failing after adding in
-lldap.

When that starts, it gives incorrect errors until it hits some check that
causes the configure script to bail out.

This results in a VERY incorrect error message being given by the
configure script.

This is similar to bug item #4133, but only a workaround was provided for
that bug, and not a proper fix.

I think in this case, putting the kerberos checks together with the ldap
stuff might solve the problem, but I'm not a configure guru.

Expected result:

Two things:
Firstly, there needs to be some form of checks against the libraries that
are added to the LIBS list so that the system catches ALL of the extra
libraries they are linked against.

Secondly, the configure script SHOULD fail sooner after errors, and give
more intelligable answers.
It should have failed right after the initial error that linking against
LDAP gave.

Actual result:
--
You can see the entire config.log file and more details at our bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=22635

snippet from config.log when it first fails:
 CUT 
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe  -L/usr/lib 
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt -lz
-lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl
-lnsl  -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure:41587: checking for ldap_start_tls_s
configure:41615: gcc -o conftest -O2 -mcpu=i686 -pipe  -L/usr/lib 
conftest.c -lldap -llber -lcrypt -lpam -lxsltbreakpoint -lxml2 -lxslt -lz
-lndbm -lgdbm -lcurl -lcrack -lbz2 -lz -lssl -lcrypto -lresolv -lm -ldl
-lnsl  -lcurl -lz -lssl -lcrypto -ldl -lz -lxml2 -lz -lm 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure:41645: checking whether to enable multibyte string support
 CUT 

Here is where it finally fails and gives up:
 CUT 
configure:75358: checking for Sablotron version
configure:75383: gcc -o conftest -O2 -mcpu=i686 -pipe  -I/usr/include
-L/usr/lib  conftest.c -lcrypt -lpspell -lpq -lpdf -lz -ltiff -lpng -ljpeg
-lmysqlclient -lmhash -lmcrypt -lltdl -lldap -llber -lcrypt -lpam
-lxsltbreakpoint -lxml2 -lxslt -lz -lndbm -lgdbm -lcurl -lcrack -lbz2 -lz
-lssl -lcrypto -lresolv -lm -ldl -lnsl  -lcurl -lz -lssl -lcrypto -ldl -lz
-lxml2 -lz -lm -lodbc -lnetsnmp -lcrypto -lm -lcrypt 15
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: libkrb4.so.2, needed by /usr/lib/libldap.so, not found (try using
-rpath or -rpath-link)
configure: failed program was:
#line 75365 configure
#include confdefs.h

#include stdlib.h
#include sablot.h

int main ()
{
double version;
version = atof(SAB_VERSION);

if (version = 0.96) {
exit(0);
}
exit(255);
}
 CUT 

The error that the above failure throws. Totally incorrect about the
problem of course.
 CUT 
checking for Sablotron version... configure: error: Sablotron version 0.96
or
greater required.
 CUT 

-- 
Edit bug report at http://bugs.php.net/?id=24141edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24141r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24141r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24141r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24141r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24141r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24141r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24141r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24141r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24141r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24141r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24141r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24141r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24141r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24141r=gnused