oneill@bass.bu.edu (Brian V O'Neill) (07/26/90)
Having just taken over a fairly large network consisting mostly of Ultrix systems, I have come across a problem. All our systems are currently running 3.0 or 3.1. While working on compiling BNews, I discovered that the libdbm.a file was corrupt on one system (ar reported not in archive format). I went to another system, and found the exact same problem. I checked practically every system, and it appears that all copies of libdbm.a are corrupt. Was it distributed like this? Is it fixed in 4.0? What is the current solution? I tried using GNU gdbm, but BNews doesn't seem to like it very much... ============================================================================ Brian O'Neill - Local Internet Access Account Internet: oneill@bu-pub.bu.edu UUCP : ...!bu.edu!bu-pub!oneill
vixie@decwrl.dec.com (Paul A Vixie) (07/26/90)
libdbm.a is really a .o file; ld(1) can read it, don't worry. [jove:vax] file /usr/lib/libdbm.a /usr/lib/libdbm.a: executable (object file) not stripped -- Paul Vixie DEC Western Research Lab <vixie@wrl.dec.com> Palo Alto, California ...!decwrl!vixie
oneill@bass.bu.edu (Brian V O'Neill) (07/26/90)
In article <VIXIE.90Jul25174547@volition.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: >libdbm.a is really a .o file; ld(1) can read it, don't worry. > >[jove:vax] file /usr/lib/libdbm.a >/usr/lib/libdbm.a: executable (object file) not stripped >-- >Paul Vixie >DEC Western Research Lab <vixie@wrl.dec.com> >Palo Alto, California ...!decwrl!vixie Yes, I figured on the object file after I did a strings on the file and saw dbm.c in there, but unfortunately nothing I try works. All the dbm functions come back as not defined during linking, although the executable is still built. The executable is useless, though, giving 'illegal instruction'. ============================================================================ Brian O'Neill - Local Internet Access Account Internet: oneill@bu-pub.bu.edu UUCP : ...!bu.edu!bu-pub!oneill
mellon@fenris.pa.dec.com (Ted Lemon) (07/27/90)
Of course, one wonders why you're bringing up BNews anyway,
considering that it's obsolete.
In any case, here's the output of ``nm /usr/lib/libdbm.a'' on a 3.1
system; it looks right. If yours is different, perhaps you had a
bad distribution tape - that would explain why it's wrong on all your
systems... BTW, you can verify that the file is correctly installed
with the following command:
% fgrep libdbm.a /usr/etc/subsets/*.inv | fverify -n
0 verification errors encountered.
0 corrections performed.
Here's the output of nm:
dbm.o:
U abort
0000113c T additem
00000004 E bitno
00000004 E blkno
U bzero
00000f94 T calchash
000011e4 T chkblk
U close
00000ec0 T cmpdatum
00000b54 T dbm_access
0000011c T dbmclose
00000104 T dbmflush
00000000 T dbminit
00000004 E dbrdonly
00000328 T delete
0000101c T delitem
00001000 C dirbuf
00000004 E dirf
000001f8 T fetch
00000a1c T firsthash
00000838 T firstkey
0000016c T forder
U fstat
00000c28 T getbit
00000f48 T hashinc
00001314 D hitab
00001354 D hltab
00000004 E hmask
U lseek
00000e38 T makdatum
00000004 E maxbno
00000874 T nextkey
00001484 g oldb1
00001488 g oldb2
U open
00000400 C pagbuf
00000004 E pagf
U printf
U read
00001470 g sccsid
00000d48 T setbit
0000047c T store
U strcat
U strcpy
U writescs@iti.org (Steve Simmons) (07/27/90)
Re all the stuff on undefined names in libdbm.a -- are you expecting this to be libndbm.a? We ran into the same problem, expecting ndbm names instead of dbm.
oneill@bass.bu.edu (Brian V O'Neill) (07/27/90)
I've figured out the problem. We have source licenses to most of our operating systems, including BSD 4.3 (we don't currently run it) and Ultrix 3.0. I looked into the source tree for BSD, and discovered sources for libdbm.a. I looked at it, and it turned out to just be an interface to libndbm routines. Well, there were no sources to libndbm.a around. It turns out that the version of libdbm.a distrbuted with Ultrix 3.X is this BSD version, but Ultrix doesn't have libndbm.a either. That is why I was getting undefined functions for dbm_*, which weren't actually called by the BNews sources. libdbm.a was calling them. So, I looked under the Ultrix source tree and found libdbm.a also. However, these were REAL sources, which did not call ndbm functions. I compiled them, and now I can compile and run everything... Now the new question is, why does DEC supply an incomplete version with the OS and a complete version with the sources? Did they only go half-way to the upgrade to ndbm? I guess I'm off to file an SPR. Thanks to all those who pointed me towards the problem... ============================================================================ Brian O'Neill - Local Internet Access Account Internet: oneill@bu-pub.bu.edu UUCP : ...!bu.edu!bu-pub!oneill
vixie@decwrl.dec.com (Paul A Vixie) (07/27/90)
>> Re all the stuff on undefined names in libdbm.a -- are you expecting >> this to be libndbm.a? We ran into the same problem, expecting ndbm >> names instead of dbm. Ultrix doesn't have libndbm. 4.3bsd keeps it in libc.a and turns libdbm.a into stubs that call the ndbm stuff. Ultrix is still based on 4.2bsd in this area -- sort of like syslog :-(. The GNU dbm routines seem to work pretty well, though, and they have an NDBM interface (among others). -- Paul Vixie DEC Western Research Lab <vixie@wrl.dec.com> Palo Alto, California ...!decwrl!vixie
douglas@dekalb.UUCP (Douglas B. Jones) (08/01/90)
In article <VIXIE.90Jul25174547@volition.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: >libdbm.a is really a .o file; ld(1) can read it, don't worry. >[jove:vax] file /usr/lib/libdbm.a >/usr/lib/libdbm.a: executable (object file) not stripped >Paul Vixie >DEC Western Research Lab <vixie@wrl.dec.com> >Palo Alto, California ...!decwrl!vixie The same is true on our Ultrix 3.0 (mv3600). If you have root access, you might want to place it in the libc.a directory or create a local lib. Maybe you might want to convert the libdbm.a from a ".o" to a ".a" and run ranlib. #cd /usr/lib #mv libdbm.a dbm.o #ar cr libdbm.a dbm.o #ranlib libdbm Make sure that the new libdbm.a is readable by everyone (chmod 644 libdbm.a). Douglas -- Doulas B. Jones douglas@dekalb Academic Computer Center or gatech!dekalb!douglas DeKalb College 555 N. Indian Creek Drive/Clarkston, Ga. 30021 (404) 299-4233