Summary: | gdbm-1.8.3/apache-1.3.31-r2/mod_ssl-2.8.19 breaks | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paul Varner (RETIRED) <fuzzyray> |
Component: | [OLD] Server | Assignee: | Chuck Short (RETIRED) <zul> |
Status: | RESOLVED DUPLICATE | ||
Severity: | critical | CC: | apache-bugs, matthias.foerste, ulm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://bugs.gentoo.org/show_bug.cgi?id=52201#c15 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
output of emerge -v --oneshot mod_ssl
output of emerge -dv --oneshot mod_ssl Patch for apache-1.3.31-r3.ebuild |
Description
Paul Varner (RETIRED)
2004-07-27 22:08:40 UTC
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 *** |