* [gentoo-dev] Possibly OT: Building mod_php-5.0.4; where is dbminit?
@ 2005-04-29 21:05 Kevin
2005-04-30 0:22 ` Georgi Georgiev
0 siblings, 1 reply; 2+ messages in thread
From: Kevin @ 2005-04-29 21:05 UTC (permalink / raw
To: gentoo-dev
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@gentoo.org mailing list
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [gentoo-dev] Possibly OT: Building mod_php-5.0.4; where is dbminit?
2005-04-29 21:05 [gentoo-dev] Possibly OT: Building mod_php-5.0.4; where is dbminit? Kevin
@ 2005-04-30 0:22 ` Georgi Georgiev
0 siblings, 0 replies; 2+ messages in thread
From: Georgi Georgiev @ 2005-04-30 0:22 UTC (permalink / raw
To: gentoo-dev
maillog: 29/04/2005-17:05:16(-0400): Kevin types
> 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)
I solved this locally like this:
--- /usr/portage/dev-php/mod_php/mod_php-5.0.3-r2.ebuild 2005-03-14 07:19:13.000000000 +0900
+++ /usr/portage-chutz/dev-php/mod_php/mod_php-5.0.3-r2.ebuild 2005-03-20 18:31:17.000000000 +0900
@@ -54,6 +54,7 @@
WANT_AUTOCONF=2.5 \
autoconf -W no-cross || die "Unable to regenerate configure script"
fi
+ sed -i -e 's!for LIB in dbm c gdbm!for LIB in dbm c gdbm gdbm_compat!' ${S}/configure
}
src_compile() {
Haven't tried 5.0.4 though.
--
) Georgi Georgiev ) "This is an outrage! I demand to know what )
( chutz@gg3.net ( happened to the plucky lawyer and her (
) +81(90)2877-8845 ) compellingly short garments." -alien )
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-04-30 0:22 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-29 21:05 [gentoo-dev] Possibly OT: Building mod_php-5.0.4; where is dbminit? Kevin
2005-04-30 0:22 ` Georgi Georgiev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox