The configure script is broken because it can't seem to find
bindtextdomain in libc.so.6 (libc-2.1.3.so) when building an RPM from
the spec for 4.0.1pl2 as given from 7.0, modifying the patches as
necessary and reconfiguring LDAP, IMAP, and MySQL as static. I did
'objdump -t /lib/libc.so.6' and bindtextdomain is in fact there, but I
don't yet know enough about configure scripts to be able to diagnose it
further.

Here's the configure command line:

./configure --target=i386-redhat-linux --prefix=/usr
--with-config-file-path=/etc --disable-debug --enable-pic
--enable-inline-optimization --enable-force-cgi-redirect
--with-exec-dir=/usr/bin --with-regex=system --with-gettext --with-gd
--with-jpeg-dir=/usr --with-png --with-zlib --with-db2 --with-db3
--with-gdbm --enable-debugger --enable-magic-quotes --enable-safe-mode
--enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp
--enable-ftp --without-mysql --with-xml --with-mysql --with-imap
--with-ldap --with-sybase-ct=/opt/sybase-11.9.2

Here's the patches that are applied to configure.in:

--- php-4.0.0/configure.in      Fri Jun 16 16:40:46 2000
+++ php-4.0.0/configure.in      Fri Jun 16 16:40:54 2000
@@ -693,7 +693,7 @@

 ZEND_MODULE_API_NO=`egrep '#define ZEND_MODULE_API_NO '
$srcdir/Zend/modules.h|sed 's/#define ZEND_MODULE_API_NO //'`

-EXTENSION_DIR="$prefix/lib/php/extensions/$PART1-$PART2-$ZEND_MODULE_AP
I_NO"
+EXTENSION_DIR="$prefix/lib/php4"

 AC_BUILD_RPATH

@@ -691,7 +691,7 @@

 EXTENSION_DIR="$prefix/lib/php4"

-PEAR_INSTALLDIR="$prefix/lib/php"
+PEAR_INSTALLDIR="$datadir/php4"

 INCLUDE_PATH=".:$PEAR_INSTALLDIR"

You need to compile and install GNU gettext :

ftp://ftp.gnu.org/gnu/gettext/gettext-0.10.tar.gz

And point --with-gettext= to the base install dir of gettext.
e.g. when libintl.a  is in /opt/gettext/lib use
--with-gettext=/opt/gettext

--Jani

Well then why is it looking for bindtextdomain in libc, and why is there
in fact a bindtextdomain in libc, and how come it's not finding it, and
how come 4.0.1pl2 doesn't have this problem?

[root@... ...]#objdump -t /lib/libc.so.6
...
00021544 g     F .text  00000016              llabs
00053998 g     F .text  00000024              _IO_sprintf
00052bd0 g     F .text  000000a9              _IO_fsetpos
0001b1e0  w    F .text  000002a6              bindtextdomain
0008afb0 g     F .text  00000037              stime
000b25e0 g     F .text  0000003d              klogctl
0001f7a0 g     F .text  00000058              sigdelset
...

Well then why is it looking for bindtextdomain in libc, and why is there
in fact a bindtextdomain in libc, and how come it's not finding it, and
how come 4.0.1pl2 doesn't have this problem?

[root@... ...]#objdump -t /lib/libc.so.6
...
00021544 g     F .text  00000016              llabs
00053998 g     F .text  00000024              _IO_sprintf
00052bd0 g     F .text  000000a9              _IO_fsetpos
0001b1e0  w    F .text  000002a6              bindtextdomain
0008afb0 g     F .text  00000037              stime
000b25e0 g     F .text  0000003d              klogctl
0001f7a0 g     F .text  00000058              sigdelset
...

My bad. I should have checked config.log. This machine is a 6.2 machine
manually upgraded to 7.0, and the person who did the upgrading didn't
install the db2 and db3 packages *grumblegrumble*.

From config.log:

...
configure:16757: checking for bindtextdomain in -lc
configure:16776: gcc -o conftest -g -O2   -L/usr/lib conftest.c -lc 
-lttf -ljpeg -lgd -l -ldb -lgdbm -lresolv -lm -ldl -lcrypt -lnsl 
-lresolv -L/usr/lib -ljpeg 1>&5
/usr/bin/ld: cannot find -l--library=db
collect2: ld returned 1 exit status
configure: failed program was:
#line 16765 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char bindtextdomain();

int main() {
bindtextdomain()
; return 0; }

Oh, and sorry about the duplicate posts. I have to remember to hit
"Cancel" when reloading the page :)

It's working after removing --with-db2 and --with-db3. The only question
that remains is why ld couldn't find /lib/libdb.so.2 and
/lib/libdb.so.3...