Why do you use system PCRE when we most likely have bundled more recent and more bug free PCRE library? Change this: --with-pcre-regex=/usr
to this: --with-pcre-regex (or just leave it out, it's enabled by default anyway)

These are also unnecessary:
--disable-rpath --disable-static

I come from a debian package that is not compiling (I was doing a custom install) for the same reason. Debian mantainers suggested to file a bug here, since I noticed that the problem arises also with the latest snapshot. The compiling options came from the standard debian configure lines.
Using --with-pcre-regex and leaving out --disable-rpath and --disable-static the segfault persists:

Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b65ccba69ea in ?? ()
(gdb) bt
#0  0x00002b65ccba69ea in ?? ()

I also tried to exclude the --with-pcre-regex option but I got the same output.

Thanks for your help,

Matteo

Well, add --enable-debug to the build and perhaps then you can get useful GDB backtrace..

Sorry, didn't notice you had --enable-debug there.
Please try this:

# rm config.cache && ./configure && make test

And if that doesn't crash, add the rest of the configure options one by one to see which causes the crash. 

You could also try this:

# USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php run-tests.php

How about you didn't add such huge piles of unasked text here next time?
I'm deleting the irrelavant part, this is relevant:

PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/lib/php/20060613-debug/curl.so' -
/usr/lib/php/20060613-debug/curl.so: cannot open shared object file: No
such file or directory in Unknown on line 0

Why don't you first disable this stuff before you do anything else?
Try "rm -rf /etc/php5" for starters..

And the sockets crash is caused by some borked library in your system..

Ok, I'll try not to post irrelevant text (but to a non-expert the crossing line is sometimes not so evident).

I downloaded today's snapshot, deleted /etc/php5 and this is the result:
- without --enable-sockets I got some failed test on some functions (I sent the report), but no more bogus "Unable to load dynamic library" lines
- with --enable-sockets I got the segfault

Core was generated by `./sapi/cli/php'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b8a7cc6c9ea in ?? ()
warning: not using untrusted file "/usr/src/tmp/php5.2-200708160430/.gdbinit"
(gdb) bt
#0  0x00002b8a7cc6c9ea in ?? ()
(gdb) quit

==29380== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==29380== For more details, rerun with: -v
==29380==
==29380== Invalid write of size 4
==29380==    at 0x55DA9EA: __db_get_lorder (in /usr/lib/libdb-4.5.so)
==29380==    by 0x7A91E50: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A91F14: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A907E2: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A90A17: _nss_db_getprotobyname_r (in /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x6F474F7: getprotobyname_r@@GLIBC_2.2.5 (getXXbyYY_r.c:210)
==29380==    by 0x6F4737F: getprotobyname (getXXbyYY.c:116)
==29380==    by 0x5FF42C: zm_startup_sockets (sockets.c:521)
==29380==    by 0x758A82: zend_startup_module_ex (zend_API.c:1466)
==29380==    by 0x7607AB: zend_hash_apply (zend_hash.c:673)
==29380==    by 0x758C80: zend_startup_modules (zend_API.c:1513)
==29380==    by 0x6F2300: php_module_startup (main.c:1802)
==29380==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29380==
==29380== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==29380==  Access not within mapped region at address 0x0
==29380==    at 0x55DA9EA: __db_get_lorder (in /usr/lib/libdb-4.5.so)
==29380==    by 0x7A91E50: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A91F14: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A907E2: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A90A17: _nss_db_getprotobyname_r (in /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x6F474F7: getprotobyname_r@@GLIBC_2.2.5 (getXXbyYY_r.c:210)
==29380==    by 0x6F4737F: getprotobyname (getXXbyYY.c:116)
==29380==    by 0x5FF42C: zm_startup_sockets (sockets.c:521)
==29380==    by 0x758A82: zend_startup_module_ex (zend_API.c:1466)
==29380==    by 0x7607AB: zend_hash_apply (zend_hash.c:673)
==29380==    by 0x758C80: zend_startup_modules (zend_API.c:1513)
==29380==    by 0x6F2300: php_module_startup (main.c:1802)
==29380==
==29380== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 4)
==29380== malloc/free: in use at exit: 998,371 bytes in 6,052 blocks.
==29380== malloc/free: 6,371 allocs, 319 frees, 1,063,402 bytes allocated.
==29380== For counts of detected errors, rerun with: -v
==29380== searching for pointers to 6,052 not-freed blocks.
==29380== checked 1,507,816 bytes.
==29380==
==29380== LEAK SUMMARY:
==29380==    definitely lost: 0 bytes in 0 blocks.
==29380==      possibly lost: 0 bytes in 0 blocks.
==29380==    still reachable: 998,371 bytes in 6,052 blocks.
==29380==         suppressed: 0 bytes in 0 blocks.
==29380== Reachable blocks (those to which a pointer was found) are not shown.
==29380== To see them, rerun with: --leak-check=full --show-reachable=yes
Segmentation fault

Is it possible to identify the improperly installed/not working library that causes the the sockets crash? If this is just a loss of time for the project I'll live without.

From the valgrind output:

==29380==    at 0x55DA9EA: __db_get_lorder (in /usr/lib/libdb-4.5.so)
==29380==    by 0x7A91E50: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A91F14: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A907E2: (within /usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x7A90A17: _nss_db_getprotobyname_r (in
/usr/lib/libnss_db-2.2.3.so)
==29380==    by 0x6F474F7: getprotobyname_r@@GLIBC_2.2.5
(getXXbyYY_r.c:210)

We only call 'getprotobyname()' in PHP. And as I can't reproduce this anywhere -> bogus.

I removed libnss_db-2.2.3.so (debian package libnss-db) from the system and everything builds fine.
I post this in the hope that it can be usefull for others.
Thanks a lot for your help!
Matteo