This problem was noted in bug# 52201, but was never addressed. After installing gdbm-1.8.3 and recompiling both apache and mod_ssl, whenever I try to start apache I get the following error. garath root # /etc/init.d/apache start * Starting apache... Syntax error on line 59 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libssl.so into server: /etc/apache/extramodules/libssl.so: undefined symbol: dbm_firstkey [ !! ] I have downgraded back to gdbm-1.8.0 and recompiled apache and mod_ssl and it works correctly again. Reproducible: Always Steps to Reproduce: 1. emerge gdbm-1.8.3 2. revdep-rebuild --soname libgdmb.so.2 to rebuild affected applications 3. emerge --oneshot mod_ssl to rebuild mod_ssl 4. /etc/init.d/apache stop 5. /etc/init.d/apache start Actual Results: Received error message: /etc/apache/extramodules/libssl.so: undefined symbol: dbm_firstkey Expected Results: Start apache with no errors Portage 2.0.51_pre13 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040619-r0, 2.6.7-gentoo-r11 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz) ================================================================= System uname: 2.6.7-gentoo-r11 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz Gentoo Base System version 1.5.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X acpi alsa arts artswrappersuid audiofile avi berkdb cdr crypt cups dvd encode fam fbcon foomaticdb gdbm gif gpm gtk gtk2 imlib java javascript jpeg kde libg++ libwww mad mbox mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls nptl oggvorbis opengl pam pda pdflib perl png ppds python qt quicktime readline sasl sdl slang spell sse ssl tcltk tcpd tiff truetype usb x86 xml2 xmms xv zlib linguas_en"
What is the result of qpkg -f /usr/include/db1/db.h
garath root # qpkg -f -v /usr/include/db1/db.h sys-libs/db-1.85-r1 *
Can you send me an output when you are emerging mod_ssl. Thanks
Created attachment 36446 [details] output of emerge -v --oneshot mod_ssl
Fixed in cvs.
It is still not working. I did an emerge sync and verified that I had the changed ebuild. When I recompiled mod_ssl, I noticed the following: /usr/lib/portage/bin/ebuild.sh: line 28: myconf: command not found Fixing the syntax error in the ebuild by changing the line: myconf = "--enable-rule=SSL_SDBM" to myconf="--enable-rule=SSL_SDBM" also didn't work. I still get the error when trying to start Apache. I'm attaching the output of emerge -dv --oneshot mod_ssl for your perusal.
Created attachment 36537 [details] output of emerge -dv --oneshot mod_ssl
Same problem here: Cannot load /etc/apache/extramodules/libssl.so into server: /etc/apache/extramodules/libssl.so: undefined symbol: dbm_firstkey dbm_firstkey is not in libgdbm.so.3, but in libgdbm_compat.so.3. Linking apache (!) with -lgdbm_compat seems to fix the problem. See attached patch.
Created attachment 37819 [details, diff] Patch for apache-1.3.31-r3.ebuild
I have some problem and this patch resolve it thanks Ulrich
I encountered this same issue on an Opteron server, after adding ~amd64 to the mod_ssl ebuild. I have successfully applied the patch (id=37819 -- thanks Ulrich). mod_ssl appears to work, i.e., apache's http(s)d is up, running and serving. Should I enter the addition of "~amd64" as a seperate "Bug?"
Meanwhile we have seen three new apache releases and the problem is still present. The patch from attachment 37819 [details, diff] does fix apache-1.3.32-r1 and -1.3.33, too.
this bug is fixed in the apache herd overlay
Can someone please !!!!!!!!!!!!!!! backport this to the main portage tree? this bug is incredibly annoying and took me hours to track down. Only to find out it's already been fixed but noone bothered to commit it to the main tree.
If gdbm_compat is the final solution, apxs has to be changed, too. line 36 (from apache-1.3.32-r1) should read: my $CFG_LIBS_SHLIB = q(-L/usr/lib -lm -lcrypt -ldb-4.1 -lmm -lexpat -lgdbm_compat -lpthread);
My previous post to this thread seems to have disappeared!, where I added that it happened on one system with Apache 1.3.33 for me (which -lgdbm_compat fixed) but not another. However, on the other, where I've restarted Apache again and again lately with no problem, just once now I ran into: Syntax error on line 61 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libssl.so into server: /etc/apache/extramodules/libssl.so: undefined symbol: dbm_firstkey However, a minute later it started just fine. This is a version compiled without the -lgdbm_compat flag - so without that fix a box can almost always, but no entirely always, work. A difference between the two boxes is that the one where that flag was 100% required had been updated more often, so maybe something intermediate in the ebuild upgrade path _almost_ gets around the need for the -lgdbm_compat flag?
Eh, frig, too early after New Years. Lost track of the terminal I was in. The just previous report the restart attempt was yet on a third, backup system where it looks like the upgrade is simply hosed because of that problem, not the system where restarting has been working just fine. So, 2 out of 3 boxes with 1.3.33 and mod_ssl: hosed.
apache-1.3.33 .ebuild has same problem with this :) but.. 1.3.33-r1 is not.. add -lgdbm_compat in LIBS (at 80th line of apache-1.3.33.ebuild ) can solve this bug.. :)
*** This bug has been marked as a duplicate of 71273 ***
