[GRASS5] ./configure --with-dbm on Debain/Testing

H_B · August 23, 2003, 10:38am

Hi,

Debian has recently changed around their GNU DBM packages a bit; the
libgdbm-dev package now provides dmb.h.

'./configure --with-dbm' gives the following error:

checking whether to use DBM... yes
checking for location of DBM includes...
checking for dbm.h... yes
checking for location of DBM library...
checking for dbminit in -ldbm... no
checking for dbminit in -lgdbm... no
checking for dbminit in -lndbm... no
configure: error: *** Unable to locate DBM library.

includes:
$ locate dbm.h
/usr/include/gdbm-ndbm.h
/usr/include/gdbm.h
/usr/include/dbm.h

libraries:
$ locate libgdbm.a
/usr/lib/libgdbm.a

$ locate libgdbm.so
/usr/lib/libgdbm.so.1.7.3
/usr/lib/libgdbm.so.1
/usr/lib/libgdbm.so.2
/usr/lib/libgdbm.so.3.0.0
/usr/lib/libgdbm.so.3
/usr/lib/libgdbm.so

http://bugs.debian.org/libgdbm-dev reports a ndbm compatability bug, if
that might have anything to do with it.

any ideas?

thanks,
Hamish

config.log output:

configure:4866: checking for location of DBM includes
configure:4892: checking for dbm.h
configure:4900: gcc -E conftest.c >/dev/null 2>conftest.out
configure:4934: checking for location of DBM library
configure:4959: checking for dbminit in -ldbm
configure:4976: gcc -o conftest -O3 -march=i686 -Wall -s conftest.c
-ldbm 1>&5/usr/bin/ld: cannot find -ldbm
collect2: ld returned 1 exit status
configure: failed program was:
#line 4965 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char dbminit();

int main() {
dbminit()
; return 0; }
configure:5001: checking for dbminit in -lgdbm
configure:5018: gcc -o conftest -O3 -march=i686 -Wall -s conftest.c
-lgdbm 1>&5/tmp/ccqKhdfm.o(.text+0xa): In function `main':
: undefined reference to `dbminit'
collect2: ld returned 1 exit status
configure: failed program was:
#line 5007 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char dbminit();

int main() {
dbminit()
; return 0; }
configure:5043: checking for dbminit in -lndbm
configure:5060: gcc -o conftest -O3 -march=i686 -Wall -s conftest.c
-lndbm 1>&5/usr/bin/ld: cannot find -lndbm
collect2: ld returned 1 exit status
configure: failed program was:
#line 5049 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char dbminit();

int main() {
dbminit()
; return 0; }

Glynn_Clements · August 23, 2003, 11:00am

Hamish wrote:

Debian has recently changed around their GNU DBM packages a bit; the
libgdbm-dev package now provides dmb.h.

'./configure --with-dbm' gives the following error:

checking whether to use DBM... yes
checking for location of DBM includes...
checking for dbm.h... yes
checking for location of DBM library...
checking for dbminit in -ldbm... no
checking for dbminit in -lgdbm... no
checking for dbminit in -lndbm... no
configure: error: *** Unable to locate DBM library.

http://bugs.debian.org/libgdbm-dev reports a ndbm compatability bug, if
that might have anything to do with it.

configure:5001: checking for dbminit in -lgdbm
configure:5018: gcc -o conftest -O3 -march=i686 -Wall -s conftest.c
-lgdbm 1>&5/tmp/ccqKhdfm.o(.text+0xa): In function `main':
: undefined reference to `dbminit'

Yep. It appears that Debian have decided to put the DBM functions into
a library called libgdbm_compat which, AFAICT, is a name used only by
Debian.

I don't know whether:

a) this package includes a symlink (e.g. libdbm -> libgdbm_compat), so
that existing packages will continue to work, or

b) they expect the rest of us to modify our configure scripts to
accomodate their change.

While b) seems pretty far-fetched, this *is* Debian, so it isn't
entirely out of the question. If it is b) then the Debian folks can
distribute their own modified GRASS package.

--
Glynn Clements <glynn.clements@virgin.net>

H_B · August 23, 2003, 12:41pm

> Debian has recently changed around their GNU DBM packages a bit; the
> libgdbm-dev package now provides dmb.h.

...

> http://bugs.debian.org/libgdbm-dev reports a ndbm compatability bug,
> if that might have anything to do with it.

...

Yep. It appears that Debian have decided to put the DBM functions into
a library called libgdbm_compat which, AFAICT, is a name used only by
Debian.

The maintainer's comments from that bug report:
"libgdbm isn't meant to be linked to libgdbm_compat; that was the whole
point of separating gdbm_compat out, so that applications using the
modern (relatively, at least) gdbm interfacte wouldn't have to also
have the added baggage of the legacy dbm interface."
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200799

I don't know whether:

a) this package includes a symlink (e.g. libdbm -> libgdbm_compat), so
that existing packages will continue to work, or

package's file list:
http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=libgdbm-dev&version=testing

$ ls -l /usr/lib/libgdbm*
/usr/lib/libgdbm.a
/usr/lib/libgdbm_compat.a
/usr/lib/libgdbm_compat.la
/usr/lib/libgdbm_compat.so -> libgdbm_compat.so.3.0.0
/usr/lib/libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0
/usr/lib/libgdbm_compat.so.3.0.0
/usr/lib/libgdbm.la
/usr/lib/libgdbm.so -> libgdbm.so.3.0.0
/usr/lib/libgdbm.so.1 -> libgdbm.so.1.7.3
/usr/lib/libgdbm.so.1.7.3
/usr/lib/libgdbm.so.2 -> libgdbm.so.1.7.3
/usr/lib/libgdbm.so.3 -> libgdbm.so.3.0.0
/usr/lib/libgdbm.so.3.0.0

so that would be no,

b) they expect the rest of us to modify our configure scripts to
accomodate their change.

While b) seems pretty far-fetched, this *is* Debian, so it isn't
entirely out of the question. If it is b) then the Debian folks can
distribute their own modified GRASS package.

It seems it is a more general GDBM switch.

From the upstream NEWS:
CHANGES from 1.8 to 1.8.1
  1. Lots of bug fixes, including a data corruption bug.
  2. Updated to current autoconf and libtool.
  3. Moved the dbm/ndbm compatibility routines to libgdbm_compat.

From the upstream changelog:
Wed Sep 25 15:19:00 PDT 2002 Jason Downs (downsj downsj.com)

        * Makefile.in: Remove the dbm and ndbm routines from the main
          library, moving them to gdbm_compat. install-compat now
          installs the compat headers and the library. Increment the
          MAJOR number of the shared library due to the removal of
          the compat functions.

* gdbm.3, gdbm.texinfo, version.c: 1.8.1; note gdbm_compat.

...

Debian Testing & Unstable use version 1.8.3-1, while Debian Stable
(3.0/Woody) uses libgdbmg1-dev 1.7.3-27

Hamish

Glynn_Clements · August 23, 2003, 3:41pm

Hamish wrote:

> > Debian has recently changed around their GNU DBM packages a bit; the
> > libgdbm-dev package now provides dmb.h.
...
> > http://bugs.debian.org/libgdbm-dev reports a ndbm compatability bug,
> > if that might have anything to do with it.
...
> Yep. It appears that Debian have decided to put the DBM functions into
> a library called libgdbm_compat which, AFAICT, is a name used only by
> Debian.

The maintainer's comments from that bug report:
"libgdbm isn't meant to be linked to libgdbm_compat; that was the whole
point of separating gdbm_compat out, so that applications using the
modern (relatively, at least) gdbm interfacte wouldn't have to also
have the added baggage of the legacy dbm interface."
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200799

Yes, I read that.

> I don't know whether:
>
> a) this package includes a symlink (e.g. libdbm -> libgdbm_compat), so
> that existing packages will continue to work, or

package's file list:
http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=libgdbm-dev&version=testing

$ ls -l /usr/lib/libgdbm*
/usr/lib/libgdbm.a
/usr/lib/libgdbm_compat.a
/usr/lib/libgdbm_compat.la
/usr/lib/libgdbm_compat.so -> libgdbm_compat.so.3.0.0
/usr/lib/libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0
/usr/lib/libgdbm_compat.so.3.0.0
/usr/lib/libgdbm.la
/usr/lib/libgdbm.so -> libgdbm.so.3.0.0
/usr/lib/libgdbm.so.1 -> libgdbm.so.1.7.3
/usr/lib/libgdbm.so.1.7.3
/usr/lib/libgdbm.so.2 -> libgdbm.so.1.7.3
/usr/lib/libgdbm.so.3 -> libgdbm.so.3.0.0
/usr/lib/libgdbm.so.3.0.0

so that would be no,

Well, I was thinking along the lines of:

/usr/lib/libdbm.so -> libgdbm_compat.so
or:
/usr/lib/libndbm.so -> libgdbm_compat.so

In which case you would be able to get the DBM routines by using -ldbm
or -lndbm, which are traditional names for the library. Both of those
names are currently checked by the configure script.

> b) they expect the rest of us to modify our configure scripts to
> accomodate their change.
>
> While b) seems pretty far-fetched, this *is* Debian, so it isn't
> entirely out of the question. If it is b) then the Debian folks can
> distribute their own modified GRASS package.

It seems it is a more general GDBM switch.

>From the upstream NEWS:
CHANGES from 1.8 to 1.8.1
  1. Lots of bug fixes, including a data corruption bug.
  2. Updated to current autoconf and libtool.
  3. Moved the dbm/ndbm compatibility routines to libgdbm_compat.

>From the upstream changelog:
Wed Sep 25 15:19:00 PDT 2002 Jason Downs (downsj downsj.com)

        * Makefile.in: Remove the dbm and ndbm routines from the main
          library, moving them to gdbm_compat. install-compat now
          installs the compat headers and the library. Increment the
          MAJOR number of the shared library due to the removal of
          the compat functions.

The point is that the NDBM (new DBM) interface (which is what GRASS
uses) has been around for years, traditionally in one of libdbm,
libndbm or libgdbm. libdbm is the name of the original library, but
some systems have a libdbm which includes both DBM and NDBM functions.
libndbm is the original name of the NDBM library (similar
functionality to DBM, but allows access to multiple tables).

libgdbm is (unsurprisingly) the GNU version, which includes both DBM
and NDBM functions, as well as a new set of functions (i.e. the GDBM
interface). At least it did, until Debian decided that they were going
to be different to every other Unix system from the last couple of
decades. But that's Debian's problem, not ours.

--
Glynn Clements <glynn.clements@virgin.net>

H_B · August 24, 2003, 3:24am

> > > Debian has recently changed around their GNU DBM packages a bit;
> > > the libgdbm-dev package now provides dmb.h.

...

> > I don't know whether:
> >
> > a) this package includes a symlink (e.g. libdbm ->
> > libgdbm_compat), so that existing packages will continue to work,
> > or...
Well, I was thinking along the lines of:
/usr/lib/libdbm.so -> libgdbm_compat.so
or:
/usr/lib/libndbm.so -> libgdbm_compat.so

Nope.
Debian should probably include that so that _compat actually *is*
compatible, I'll suggest that in the bug report, although I have to
admit I'm mostly stumbling my way through here.

In which case you would be able to get the DBM routines by using -ldbm
or -lndbm, which are traditional names for the library. Both of those
names are currently checked by the configure script.

Once I add the following link, ./configure gets past the DBM check.

ln -s /usr/lib/libgdbm_compat.so /usr/local/lib/libdbm.so
(and add /usr/local/lib to /etc/ld.so.conf & run /sbin/ldconfig)

But I haven't tried a full recompile with it yet.

[aside- that says something for Debian, this install is 2.5 years old,
and I've never had to modify ld.so.conf for /usr/local/lib before.
Usually have to hit Redhat with that in the first 10 minutes. Surprises
me I never had to do it before.]

> > While b) seems pretty far-fetched, this *is* Debian, so it isn't
> > entirely out of the question. If it is b) then the Debian folks
> > can distribute their own modified GRASS package.

Absolutely, if that's the case.

libgdbm is (unsurprisingly) the GNU version, which includes both DBM
and NDBM functions, as well as a new set of functions (i.e. the GDBM
interface). At least it did, until Debian decided that they were going
to be different to every other Unix system from the last couple of
decades. But that's Debian's problem, not ours.

Again, I think this is a change in the GNU version, which Debian is just
shadowing.

libgdbm_compat exists in the latest versions here, for example:
http://www.ibiblio.org/pub/gnu/gdbm/

shrug
Just something to look out for in the future.

Hamish

Glynn_Clements · August 24, 2003, 4:17am

Hamish wrote:

> libgdbm is (unsurprisingly) the GNU version, which includes both DBM
> and NDBM functions, as well as a new set of functions (i.e. the GDBM
> interface). At least it did, until Debian decided that they were going
> to be different to every other Unix system from the last couple of
> decades. But that's Debian's problem, not ours.

Again, I think this is a change in the GNU version, which Debian is just
shadowing.

libgdbm_compat exists in the latest versions here, for example:
http://www.ibiblio.org/pub/gnu/gdbm/

Oh dear.

Fortunately, it doesn't appear that anything actually uses dbm.h. The
checks were originally added because David D Gray implied back in Jan
2002 that he wanted to use them for v.in.shape/v.in.mif, but I can't
find any trace of DBM/NDBM/GDBM actually being used.

The easiest solution would seem to be to simply remove the checks, and
set aside the issue of whether to accomodate this particular piece of
GNU idiocy until it actually has to be addressed.

--
Glynn Clements <glynn.clements@virgin.net>

Markus_Neteler1 · August 24, 2003, 4:36pm

On Sun, Aug 24, 2003 at 05:17:49AM +0100, Glynn Clements wrote:

Hamish wrote:

> > libgdbm is (unsurprisingly) the GNU version, which includes both DBM
> > and NDBM functions, as well as a new set of functions (i.e. the GDBM
> > interface). At least it did, until Debian decided that they were going
> > to be different to every other Unix system from the last couple of
> > decades. But that's Debian's problem, not ours.
>
> Again, I think this is a change in the GNU version, which Debian is just
> shadowing.
>
> libgdbm_compat exists in the latest versions here, for example:
> http://www.ibiblio.org/pub/gnu/gdbm/

Oh dear.

Fortunately, it doesn't appear that anything actually uses dbm.h. The
checks were originally added because David D Gray implied back in Jan
2002 that he wanted to use them for v.in.shape/v.in.mif, but I can't
find any trace of DBM/NDBM/GDBM actually being used.

As far as I remember he never got finished/started that DBM
implementation.

The easiest solution would seem to be to simply remove the checks, and
set aside the issue of whether to accomodate this particular piece of
GNU idiocy until it actually has to be addressed.

This should be the best solution. Why confusing users with
test for non-used packages? If agreed we should also update
the release branch then.

Markus

H_B · September 22, 2003, 12:11pm

> > libgdbm is (unsurprisingly) the GNU version, which includes both
> > DBM and NDBM functions, as well as a new set of functions (i.e.
> > the GDBM interface). At least it did, until Debian decided that
> > they were going to be different to every other Unix system from
> > the last couple of decades. But that's Debian's problem, not ours.
>
> Again, I think this is a change in the GNU version, which Debian is
> just shadowing.
>
> libgdbm_compat exists in the latest versions here, for example:
> http://www.ibiblio.org/pub/gnu/gdbm/

Oh dear.

Fortunately, it doesn't appear that anything actually uses dbm.h. The
checks were originally added because David D Gray implied back in Jan
2002 that he wanted to use them for v.in.shape/v.in.mif, but I can't
find any trace of DBM/NDBM/GDBM actually being used.

The easiest solution would seem to be to simply remove the checks, and
set aside the issue of whether to accomodate this particular piece of
GNU idiocy until it actually has to be addressed.

FYI, this patch was posted to the Debian bug system re. the above bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203834

diff -ru grass-4.99+5.0.0pre4.debian/configure.in grass-4.99+5.0.0pre4/configure.in
--- grass-4.99+5.0.0pre4.debian/configure.in 2003-09-02 18:33:48.000000000 +0200
+++ grass-4.99+5.0.0pre4/configure.in 2003-09-02 18:35:59.000000000 +0200
@@ -501,9 +501,11 @@

LOC_CHECK_LIBS(dbm, dbminit,DBM,$DBMLIBPATH,DBMLIB,[
LOC_CHECK_LIBS(gdbm,dbminit,DBM,$DBMLIBPATH,DBMLIB,[
+LOC_CHECK_LIBS(gdbm_compat,dbminit,DBM,$DBMLIBPATH,DBMLIB,[
LOC_CHECK_LIBS(ndbm,dbminit,DBM,$DBMLIBPATH,DBMLIB,)
])
])
+])

fi # $USE_DBM

Hamish

Markus_Neteler1 · September 22, 2003, 12:21pm

On Tue, Sep 23, 2003 at 12:11:22AM +1200, Hamish wrote:

> > > libgdbm is (unsurprisingly) the GNU version, which includes both
> > > DBM and NDBM functions, as well as a new set of functions (i.e.
> > > the GDBM interface). At least it did, until Debian decided that
> > > they were going to be different to every other Unix system from
> > > the last couple of decades. But that's Debian's problem, not ours.
> >
> > Again, I think this is a change in the GNU version, which Debian is
> > just shadowing.
> >
> > libgdbm_compat exists in the latest versions here, for example:
> > http://www.ibiblio.org/pub/gnu/gdbm/
>
> Oh dear.
>
> Fortunately, it doesn't appear that anything actually uses dbm.h. The
> checks were originally added because David D Gray implied back in Jan
> 2002 that he wanted to use them for v.in.shape/v.in.mif, but I can't
> find any trace of DBM/NDBM/GDBM actually being used.
>
> The easiest solution would seem to be to simply remove the checks, and
> set aside the issue of whether to accomodate this particular piece of
> GNU idiocy until it actually has to be addressed.

FYI, this patch was posted to the Debian bug system re. the above bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203834

diff -ru grass-4.99+5.0.0pre4.debian/configure.in grass-4.99+5.0.0pre4/configure.in
--- grass-4.99+5.0.0pre4.debian/configure.in 2003-09-02 18:33:48.000000000 +0200
+++ grass-4.99+5.0.0pre4/configure.in 2003-09-02 18:35:59.000000000 +0200
@@ -501,9 +501,11 @@

LOC_CHECK_LIBS(dbm, dbminit,DBM,$DBMLIBPATH,DBMLIB,[
LOC_CHECK_LIBS(gdbm,dbminit,DBM,$DBMLIBPATH,DBMLIB,[
+LOC_CHECK_LIBS(gdbm_compat,dbminit,DBM,$DBMLIBPATH,DBMLIB,[
LOC_CHECK_LIBS(ndbm,dbminit,DBM,$DBMLIBPATH,DBMLIB,)
])
])
+])

fi # $USE_DBM

Note, there was this answer from Glynn

http://grass.itc.it/pipermail/grass5/2003-August/012466.html

Markus