gdbm 1.8

[Roger]

Hello:

I'm not exactly sure if this is a bug or a 'user headspace error' on my
part.  I've been tring to compile gdbm 1.8 on my sparc running solaris 8
-with gcc 2.95.2.

While compiling this I think I stumbled into a common probem with gdbm
that others had as well.

When doing the 'make progs' I'd always get this error 

gcc  -o tdbm testdbm.o -lc
Undefined                       first referenced
 symbol                             in file
fetch                               testdbm.o
nextkey                             testdbm.o
delete                              testdbm.o
store                               testdbm.o
dbminit                             testdbm.o
firstkey                            testdbm.o
ld: fatal: Symbol referencing errors. No output written to tdbm
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `tdbm'


Looking around usenet one person, better programmer then I, pointed this
out.  

With the below problem brought to light would this require gdbm 1.8.1 to
be released???

Thanks..

-------------------------------------------------------------------
From: address@hidden (address@hidden)
 Subject: Minor bug in gdbm-1.8.0 
 Newsgroups: gnu.utils.bug
 Date: 2001-05-13 16:30:44 PST 



Gentle GDBM experts,

Thank you for providing such a clean package.  I was able to
port it to the POSIX.1 environment on the Stratus VOS operating
system without serious difficulty.  It compiles cleanly with GCC
2.95.2 and almost cleanly with the VOS Standard C compiler (our
own implementation of the ANSI C Standard).

Our own C compiler is quite strict in its default mode and so I
discovered that neither testgdbm.c nor testngdbm.c declares the
"exit" library routine.  Unlike some other C library routines,
exit is a subroutine, and so its default declaration as a
function leads to a linker warning on our implementation.  There
are other missing function declarations (see below) but at least
these are truly functions and I get only a trivial compiler
warning that I can easily suppress.  I have no way to suppress
the linker warning about the bad declaration.

It appears to me that this is a simple fix:  merely include the
stdlib.h header.  Here is a patch that takes care of this:

*** testdbm.c.orig      Tue May 18 20:16:07 1999
--- testdbm.c   Sat May 12 21:59:54 2001
***************
*** 31,36 ****
--- 31,39 ----
  #include "autoconf.h"
  
  #include <stdio.h>
+ #if HAVE_STDLIB_H
+ #include <stdlib.h>
+ #endif
  #include <sys/types.h>
  #if HAVE_SYS_FILE_H
  #include <sys/file.h>
*** testndbm.c.orig     Tue May 18 20:16:07 1999
--- testndbm.c  Sat May 12 22:01:13 2001
***************
*** 31,36 ****
--- 31,39 ----
  #include "autoconf.h"
  
  #include <stdio.h>
+ #if HAVE_STDLIB_H
+ #include <stdlib.h>
+ #endif
  #include <sys/types.h>
  #if HAVE_FILE_H
  #include <sys/file.h>

The other missing declarations are:

gdbmopen.c              missing ftruncate.
testdbm.c                       missing dbminit, strlen, store, delete.
testndbm.c              missing strlen.

I had one additional issue.  We do not use Unix-style library
files on VOS.  Instead, we create a file system directory that
holds all of the compiled object files, we add symbolic links in
this directory to list all of the external names and show which
file defines them, and our linker then searches a list of these
object file directories.  It confuses us greatly when someone
names a user object file as the same name as a C library
function, because we end up finding the user object file.  I
renamed two of the compiled object files to avoid this problem:

        dbmclose.obj    renamed to      dbm_close.obj
        close.obj               renamed to      dbmclose.obj

In both cases, the file name now agrees with the external name
that the file defines, and our linker is happy.

I hope you will consider making these changes in a future release.

Again, thanks for providing and for maintaining GNU GDBM.

Thanks
PG
--
Paul Green                  | Mail: address@hidden
Senior Technical Consultant | Voice: +1 978-461-7557   FAX: +1
978-461-3610
Stratus Computer            | Video: PictureTel/AT&T by request.
Maynard, MA  01754          | Disclaimer: I speak for myself, not Stratus.


 From: address@hidden (address@hidden)
 Subject: Minor bug in gdbm-1.8.0 
 Newsgroups: gnu.utils.bug
 Date: 2001-05-14 14:51:04 PST 



Ooops.  I reported that gdbmopen.c does not declare ftruncate.
This is my mistake.  Once I set _POSIX_C_SOURCE up to a higher
level, the function was properly declared by unistd.h.  I
apologize for the error.

Thanks
PG
--
Paul Green                  | Mail: address@hidden
Senior Technical Consultant | Voice: +1 978-461-7557   FAX: +1
978-461-3610
Stratus Computer            | Video: PictureTel/AT&T by request.
Maynard, MA  01754          | Disclaimer: I speak for myself, not Stratus.