[gentoo-dev] Possibly OT: Building mod_php-5.0.4; where is dbminit?

[Kevin]

Hi Devs-

Sorry if it's OT, but nobody in -user seems to have a clue on this one.

I'm trying to build mod_php-5.0.4 with an ebuild script that is a
renamed copy of the one in portage for version 5.0.3-r2.  I've got it in
my portage overlay and I've adjusted the patch files and so forth to get
it working.  As far as the ebuild goes, I'm pretty sure everything is
fine.  Anyway, the same thing happens with unmodified 5.0.3-r2 from
portage so it's definitely not my ebuild that is the problem.

The trouble is, in building, the configure script fails at:

checking whether to enable DBA... yes
checking for QDBM support... no
checking for gdbm_open in -lgdbm... yes
checking for GDBM support... yes
checking for NDBM support... no
checking for db4 minor version and patch level... ok
checking for Berkeley DB4 support... yes
checking for Berkeley DB3 support... no
checking for Berkeley DB2 support... no
checking for dbminit in -ldbm... no
checking for dbminit in -lc... no
checking for dbminit in -lgdbm... no
configure: error: DBA: Could not find necessary library.

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/mod_php-5.0.4/work/php-5.0.4/config.log
(pertinent lines from this file included below)

Now, on a very similar server, I did successfully build mod_php-5.0.4 in
the same way as I'm attempting to do here.  The ebuild script is
identical, the missing-arches patch file is present but has no content
(on both servers).  On this server, the configure script sails through
this part with the following output:

checking whether to enable DBA... yes
checking for QDBM support... no
checking for gdbm_open in -lgdbm... yes
checking for GDBM support... yes
checking for NDBM support... no
checking for db4 minor version and patch level... ok
checking for Berkeley DB4 support... yes
checking for Berkeley DB3 support... no
checking for Berkeley DB2 support... no
checking for dbminit in -ldbm... no
checking for dbminit in -lc... yes
checking for DBM using GDBM... no
checking for DBM support... yes
checking for CDB support... builtin
checking for INI File support... builtin
checking for FlatFile support... builtin
checking whether to enable DBA interface... yes

The difference is that on the second (successful mod_php-5.0.4 build)
server, the config script finds dbminit in -lc (glibc right?), but on
the first server, it doesn't find dbminit in any of the places it looks.

I can't figure out what the difference is here.  Am I being thick-headed
or something?  The two machines do have different glibc versions, but
the first machine (fails to build mod_php) has a newer glibc version:

machine 1 (fails):    glibc-2.3.4.20041102-r1
machine 2 (succeeds): glibc-2.3.4.20040808-r1

They were both built using the same USE flags:
machine 1:
machine1 root # emerge -av glibc

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] sys-libs/glibc-2.3.4.20041102-r1  -build -debug -erandom
-hardened (-multilib) +nls -nomalloccheck -nptl -nptlonly -pic
-userlocales 0 kB

machine 2:
machine2 php-5.0.4 # emerge -av glibc

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild     U ] sys-libs/glibc-2.3.4.20041102-r1 [2.3.4.20040808-r1]
-build -debug -erandom -hardened (-multilib) +nls -nomalloccheck -nptl
-nptlonly -pic -userlocales 2,963 kB


Is it perhaps the case that dbminit used to be present in glibc but is
no longer?  But I don't see it with strings even in the older
(successful) machine's glibc files:

machine2 lib # pwd
/usr/lib
machine2 lib # for i in *; do  strings $i|grep dbminit && echo "In
Library File $i"; done 2> /dev/null
dbminit
dbminit.o/      1084750600  0     0     100644  1752      `
dbminit.c
dbminit
In Library File libgdbm.a
dbminit
In Library File libgdbm.so
dbminit
In Library File libgdbm.so.2
dbminit
In Library File libgdbm.so.2.0.0
kdb2_dbminit
In Library File libkdb5.so
kdb2_dbminit
In Library File libkdb5.so.4
kdb2_dbminit
In Library File libkdb5.so.4.0

machine2 lib # pwd
/lib
machine2 lib # for i in *; do  strings $i|grep dbminit && echo "In
Library File $i"; done 2> /dev/null

machine2 root # for i in `epm -ql glibc`; do  strings $i|grep dbminit &&
echo "In Library File $i"; done 2> /dev/null
machine2 root #



Can somebody clue me in here?  Is dbminit really somewhere in glibc as
the mod_php configure script on machine 2 seems to be saying?  By doing
strings filename|grep dbminit I don't see it anywhere although I'm sure
there's a better way of hunting for it (just don't know what it is).

On both machines, I'm using identical USE flags for mod_php:

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] dev-php/mod_php-5.0.4  -adabas +apache2 +bcmath +berkdb
-birdstep +bzlib +calendar +cdb +cpdflib +crypt +ctype +curl
+curlwrappers -db2 +dba -dbase +dbm -dbmaker -dbx -debug -dio -empress
-empress-bcs -esoob +exif +fam +fdftk +filepro +firebird +flatfile
-frontbase +ftp +gd -gd-external +gdbm +gmp -hyperwave-api +iconv +imap
-informix -ingres +inifile -iodbc +jpeg +kerberos +ldap -libedit +mcve
-memlimit +mhash +mime +ming -mnogosearch -msession -msql -mssql +mysql
-mysqli +ncurses +nis +nls -oci8 +odbc -oracle7 -ovrimos -pcntl +pcre
-pfpro +png +posix +postgres -qdbm +readline -recode -sapdb +sasl
+session -sharedext +sharedmem +simplexml -snmp +soap -sockets -solid
+spell +spl +sqlite +ssl -sybase -sybase-ct +sysvipc -threads +tidy
+tiff +tokenizer +truetype -wddx +xml2 +xmlrpc +xpm +xsl +zlib 0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

When I look for dbminit functions in library files, I'm only getting
finds in gdbm libraries on either machine.  I don't understand why the
config script isn't finding it in -lgdbm on machine 1 because I see it
when I do the strings search above.  Different dbminit or something?

Can anyone see why configure fails on machine 1 but succeeds on machine
2?  Pertinent lines from config.log here:

   5893 | /* We use char because int might match the return type of a gcc2
   5894 |    builtin and then its argument prototype would still apply.  */
   5895 | char dbminit ();
   5896 | int
   5897 | main ()
   5898 | {
   5899 | dbminit ();
   5900 |   ;
   5901 |   return 0;
   5902 | }
   5903 configure:35562: result: no
   5904 configure:35500: checking for dbminit in -lc
   5905 configure:35530: i686-pc-linux-gnu-gcc -o conftest -O2
-march=pentium4 -
   5905 fomit-frame-pointer -pipe  -L/usr/lib  conftest.c -lc  -ldb-4.2
-ldb-4.2
   5905  -lgdbm -lcurl -lcpdf -ltiff -ljpeg -lbz2 -lz -lresolv -lm -ldl
-lnsl  -
   5905 lxml2 -lz -lm -lssl -lcrypto -ldl -lcurl -lssl -lcrypto -ldl
-lssl -lcry
   5905 pto -ldl -lz >&5
   5906 /var/tmp/portage/mod_php-5.0.3-r2/temp/ccDBbNuu.o(.text+0xa): In
functio
   5906 n `main':
   5907 : undefined reference to `dbminit'
   5908 collect2: ld returned 1 exit status
   5909 distcc[20096] ERROR: compile conftest.c on localhost failed
   5910 configure:35536: $? = 1

I've tried it with distcc turned off too.

Any help would be much appreciated.

-Kevin
http://www.gnosys.us
-- 
gentoo-dev@g.o mailing list