You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Jacobowitz <dr...@false.org> on 1998/09/12 03:47:02 UTC

[patch] Glibc 2.1 / DB 2.0 support

What with all the setup problems I've been having, I'm not sure whether
this got out at all last time, so here we go again...

This patch allows apache 1.3.1 to compile and run on a LinuxPPC glibc
2.0.95 machine.  The shared library stuff should be better fixed with
SHARED_CHAIN although I don't have a snapshot at present to try to fix
that on; the header changes are fine by themselves, though.

I would really like to see this in 1.3.2 if possible....too late for
that?

Dan


Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Marc Slemko <ma...@znep.com>.
Unfortunately, the only real solution is to make our own *db* library,
give it some gawdawful name so no conflicts are possible, and say that we
don't support anyone using anything else.

Sigh.  

I will go no further in my annoyance except to say that someone should be
darn sorry and it isn't you.  <g>

On Sat, 12 Sep 1998, Dean Gaudet wrote:

> Ok sorry.  I just don't want to have anything to do with it :)
> 
> Dean
> 
> On Sat, 12 Sep 1998, Marc Slemko wrote:
> 
> > On Sat, 12 Sep 1998, Dean Gaudet wrote:
> > 
> > > 
> > > 
> > > On Sat, 12 Sep 1998, Dan Jacobowitz wrote:
> > > 
> > > > That's my point exactly.  The __GLIBC_MINOR__ + __GLIBC__ >= 3 will
> > > > fail for Redhat 5.1 - which is glibc 2.0 based.  Only in glibc 2.1 will
> > > > it succeed, and in glibc 2.1, db.h is for db version 2 (libdb2 on most
> > > > current systems that have it).  The two are not binary compatible.
> > > 
> > > !@#$% fucking glibc developers.  Why the hell can't they maintain any
> > > shred of compatibility? 
> > > 
> > > I don't want to have anything to do with this.  It's stupid.  I'm tired of
> > > putting in fucking kludges for every new version of glibc.  None of the
> > > commercial vendors are this bad, and they can be pretty capricious at
> > > times.
> > > 
> > > If db2.0 is a completely brand new, non-backwards compatible db library
> > > then it shouldn't be linked with -ldb and shouldn't be #include "db.h". 
> > 
> > db2 with completely incompatible interfaces using the same -l and header
> > files has been around for a long time.  Most people just use the db_185.h
> > or whatever it is and install it as db.h, and the problem goes away.
> > 
> > So they didn't invent the dumbness, just decided to listen to the people
> > who did.  I would guess that is Bostic, sigh.
> > 
> > The "proper" solution is to add a db2 auth module, then have it detect if
> > -ldb and db.h support the "old" db or the "new" db.  Of course, even if
> > -ldb is db2, you may still have to use the 1.85 api on most systems.
> > 
> > db1.85 and db2 files aren't compatible, but files created using the 1.85
> > compat interface to db2 are compatible with db2 files.
> > 
> > 
> > 
> 
> 


Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Dean Gaudet <dg...@arctic.org>.
Ok sorry.  I just don't want to have anything to do with it :)

Dean

On Sat, 12 Sep 1998, Marc Slemko wrote:

> On Sat, 12 Sep 1998, Dean Gaudet wrote:
> 
> > 
> > 
> > On Sat, 12 Sep 1998, Dan Jacobowitz wrote:
> > 
> > > That's my point exactly.  The __GLIBC_MINOR__ + __GLIBC__ >= 3 will
> > > fail for Redhat 5.1 - which is glibc 2.0 based.  Only in glibc 2.1 will
> > > it succeed, and in glibc 2.1, db.h is for db version 2 (libdb2 on most
> > > current systems that have it).  The two are not binary compatible.
> > 
> > !@#$% fucking glibc developers.  Why the hell can't they maintain any
> > shred of compatibility? 
> > 
> > I don't want to have anything to do with this.  It's stupid.  I'm tired of
> > putting in fucking kludges for every new version of glibc.  None of the
> > commercial vendors are this bad, and they can be pretty capricious at
> > times.
> > 
> > If db2.0 is a completely brand new, non-backwards compatible db library
> > then it shouldn't be linked with -ldb and shouldn't be #include "db.h". 
> 
> db2 with completely incompatible interfaces using the same -l and header
> files has been around for a long time.  Most people just use the db_185.h
> or whatever it is and install it as db.h, and the problem goes away.
> 
> So they didn't invent the dumbness, just decided to listen to the people
> who did.  I would guess that is Bostic, sigh.
> 
> The "proper" solution is to add a db2 auth module, then have it detect if
> -ldb and db.h support the "old" db or the "new" db.  Of course, even if
> -ldb is db2, you may still have to use the 1.85 api on most systems.
> 
> db1.85 and db2 files aren't compatible, but files created using the 1.85
> compat interface to db2 are compatible with db2 files.
> 
> 
> 


Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Marc Slemko <ma...@znep.com>.
On Sat, 12 Sep 1998, Dean Gaudet wrote:

> 
> 
> On Sat, 12 Sep 1998, Dan Jacobowitz wrote:
> 
> > That's my point exactly.  The __GLIBC_MINOR__ + __GLIBC__ >= 3 will
> > fail for Redhat 5.1 - which is glibc 2.0 based.  Only in glibc 2.1 will
> > it succeed, and in glibc 2.1, db.h is for db version 2 (libdb2 on most
> > current systems that have it).  The two are not binary compatible.
> 
> !@#$% fucking glibc developers.  Why the hell can't they maintain any
> shred of compatibility? 
> 
> I don't want to have anything to do with this.  It's stupid.  I'm tired of
> putting in fucking kludges for every new version of glibc.  None of the
> commercial vendors are this bad, and they can be pretty capricious at
> times.
> 
> If db2.0 is a completely brand new, non-backwards compatible db library
> then it shouldn't be linked with -ldb and shouldn't be #include "db.h". 

db2 with completely incompatible interfaces using the same -l and header
files has been around for a long time.  Most people just use the db_185.h
or whatever it is and install it as db.h, and the problem goes away.

So they didn't invent the dumbness, just decided to listen to the people
who did.  I would guess that is Bostic, sigh.

The "proper" solution is to add a db2 auth module, then have it detect if
-ldb and db.h support the "old" db or the "new" db.  Of course, even if
-ldb is db2, you may still have to use the 1.85 api on most systems.

db1.85 and db2 files aren't compatible, but files created using the 1.85
compat interface to db2 are compatible with db2 files.



Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Dean Gaudet <dg...@arctic.org>.

On Sat, 12 Sep 1998, Dan Jacobowitz wrote:

> That's my point exactly.  The __GLIBC_MINOR__ + __GLIBC__ >= 3 will
> fail for Redhat 5.1 - which is glibc 2.0 based.  Only in glibc 2.1 will
> it succeed, and in glibc 2.1, db.h is for db version 2 (libdb2 on most
> current systems that have it).  The two are not binary compatible.

!@#$% fucking glibc developers.  Why the hell can't they maintain any
shred of compatibility? 

I don't want to have anything to do with this.  It's stupid.  I'm tired of
putting in fucking kludges for every new version of glibc.  None of the
commercial vendors are this bad, and they can be pretty capricious at
times.

If db2.0 is a completely brand new, non-backwards compatible db library
then it shouldn't be linked with -ldb and shouldn't be #include "db.h". 
This breaks any existing tool which was compiled with db-1.85, and which
is recompiled (without a single source change) against glibc 2.1.  What
the hell are they thinking? 

> I'm now having another problem: I don't want all modules to be linked
> to both libgdbm and libdb since both provide dbm_open - that would
> probably produce fairly undesirable results.  I had to add specific
> rules for mod_rewrite.so, mod_auth_db.so, and mod_auth_dbm.so to fix
> this.

You have to link -lgdbm first, -ldb second.  This worked months and months
ago when I first put in code to figure out which db library to use.  I've
no idea if it works now. 

It sounds like we need per-module LIBS/etc.  I haven't been paying
attention to any of the config stuff in the past few months, so I've no
idea if we have that.

I regret ever putting in auto libdb/dbm/gdbm/etc. detection.  There's no
sane way to do it which works for all the fucked up linux distributions
out there. 

Dean


Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Dan Jacobowitz <dr...@false.org>.
On Sat, Sep 12, 1998 at 12:57:43AM -0700, Dean Gaudet wrote:
> Sorry but this patch is broken.

Let's see what I can do about that...

> You've just screwed over everyone who has libdb installed, and who built
> a previous version of apache... libdb always has dbm_open.  By testing
> for it first you break binary compatibility with any existing dbm file.

Argh - I wasn't aware all versions of libdb provided this emulation,
and I was working too late at night.

> + #if defined(__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC_MINOR__ + __GLIBC__ >= 3)
> + #include <db_185.h>
> + #else
>   #include <db.h>
> + #endif
> + 
> 
> No way.  I don't see any db_185.h on my glibc system.  (Redhat 5.1)

That's my point exactly.  The __GLIBC_MINOR__ + __GLIBC__ >= 3 will
fail for Redhat 5.1 - which is glibc 2.0 based.  Only in glibc 2.1 will
it succeed, and in glibc 2.1, db.h is for db version 2 (libdb2 on most
current systems that have it).  The two are not binary compatible.

> *** apache-1.3.1/src/modules/standard/mod_auth_dbm.c	Fri Jul  3 18:08:50 1998
> --- apache-ppc/src/modules/standard/mod_auth_dbm.c	Tue Sep  1 18:49:35 1998
>
> This should be completely unnecessary.  If you're building with libdb then
> use mod_auth_db.  There's a reason that there are two modules that look
> almost the same.

Argh!  Now I see where the problem was coming from - the debian build
process was assuming the necessary headers for mod_auth_dbm were
available, but they were not.

I'm now having another problem: I don't want all modules to be linked
to both libgdbm and libdb since both provide dbm_open - that would
probably produce fairly undesirable results.  I had to add specific
rules for mod_rewrite.so, mod_auth_db.so, and mod_auth_dbm.so to fix
this.

It looks like I cleaned almost everything up - the one thing about
which I am dubious is having httpd be linked to both -ldbm and -ldb as
seems to happen with gdbm and db 2 installed, but since I am explicitly
linking the shared modules in this case there should be no problem.  I
imagine this would break if the modules were compiled in statically,
but I'm not sure what to do about that, and I don't think this one is
my fault.


A revised and cleaned up version of the patch is below.  Apologies for
some of the stupidities of the last one.

Dan

Re: [patch] Glibc 2.1 / DB 2.0 support

Posted by Dean Gaudet <dg...@arctic.org>.
Sorry but this patch is broken.

*** apache-1.3.1/src/helpers/find-dbm-lib	Tue Apr 14 06:58:23 1998
--- apache-ppc/src/helpers/find-dbm-lib	Tue Sep  1 21:44:26 1998
***************
*** 13,19 ****
  	    *-linux*)
  		# many systems don't have -ldbm
  		DBM_LIB=""
! 		if ./helpers/TestCompile lib dbm dbm_open; then
  		    DBM_LIB="-ldbm"
  		elif ./helpers/TestCompile lib ndbm dbm_open; then
  		    DBM_LIB="-lndbm"
--- 13,22 ----
  	    *-linux*)
  		# many systems don't have -ldbm
  		DBM_LIB=""
! 		# if it's in libdb, use that one.
! 		if ./helpers/TestCompile lib db dbm_open; then
! 		    DBM_LIB="-ldb"
! 		elif ./helpers/TestCompile lib dbm dbm_open; then
  		    DBM_LIB="-ldbm"
  		elif ./helpers/TestCompile lib ndbm dbm_open; then
  		    DBM_LIB="-lndbm"


You've just screwed over everyone who has libdb installed, and who built
a previous version of apache... libdb always has dbm_open.  By testing
for it first you break binary compatibility with any existing dbm file.

diff -cNr apache-1.3.1/src/modules/standard/mod_auth_db.c apache-ppc/src/modules/standard/mod_auth_db.c
*** apache-1.3.1/src/modules/standard/mod_auth_db.c	Fri Jul  3 18:08:50 1998
--- apache-ppc/src/modules/standard/mod_auth_db.c	Mon Sep  7 18:37:03 1998
***************
*** 95,101 ****
--- 95,106 ----
  #include "http_core.h"
  #include "http_log.h"
  #include "http_protocol.h"
+ #if defined(__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC_MINOR__ + __GLIBC__ >= 3)
+ #include <db_185.h>
+ #else
  #include <db.h>
+ #endif
+ 
  
  typedef struct {

No way.  I don't see any db_185.h on my glibc system.  (Redhat 5.1)

diff -cNr apache-1.3.1/src/modules/standard/mod_auth_dbm.c apache-ppc/src/modules/standard/mod_auth_dbm.c
*** apache-1.3.1/src/modules/standard/mod_auth_dbm.c	Fri Jul  3 18:08:50 1998
--- apache-ppc/src/modules/standard/mod_auth_dbm.c	Tue Sep  1 18:49:35 1998
***************
*** 74,80 ****
--- 74,85 ----
  #include "http_core.h"
  #include "http_log.h"
  #include "http_protocol.h"
+ #if defined(__GLIBC__) && (__GLIBC__ >= 2) && (__GLIBC__ + __GLIBC_MINOR__ >= 3)
+ #define DB_DBM_HSEARCH 1
+ #include <db.h>
+ #else
  #include <ndbm.h>
+ #endif
  
  /*
   * Module definition information - the part between the -START and -END

This should be completely unnecessary.  If you're building with libdb then
use mod_auth_db.  There's a reason that there are two modules that look
almost the same.

Dean