Closed Bug 158649 Opened 22 years ago Closed 22 years ago

compile error in cdbhdl.h / dbinit.c

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: BenB, Assigned: wtc)

Details

When trying to compile Mozilla on the 1.0 branch, I get the compile error below.
This happens on 2 different machines, both of which were able to compile the
branch just 2 weeks ago. The error must have appeared sometime between Jul 8 and
Jul 17.
I use Debian 3.0 and unstable.

Unless I am missing something and this is my error, please fix this before the
1.0.1 release.

cd softoken; make -j1 libs
In file included from dbinit.c:47:
cdbhdl.h:43: mcom_db.h: No such file or directory
In file included from dbinit.c:47:
cdbhdl.h:50: parse error before `DB'
cdbhdl.h:50: warning: no semicolon at end of struct or union
cdbhdl.h:52: parse error before `}'
cdbhdl.h:64: parse error before `*'
cdbhdl.h:65: warning: type defaults to `int' in declaration of `rdbfunc'
cdbhdl.h:65: warning: data definition has no type or storage class
cdbhdl.h:67: parse error before `*'
cdbhdl.h:68: warning: type defaults to `int' in declaration of `rdbopen'
cdbhdl.h:68: warning: data definition has no type or storage class
cdbhdl.h:70: parse error before `*'
dbinit.c: In function `pk11_OpenCertDB':
dbinit.c:147: sizeof applied to an incomplete type
dbinit.c: At top level:
dbinit.c:258: parse error before `pk11_rdbfunc'
dbinit.c:258: warning: type defaults to `int' in declaration of `pk11_rdbfunc'
dbinit.c:258: warning: data definition has no type or storage class
dbinit.c:263: parse error before `*'
dbinit.c:265: warning: return-type defaults to `int'
dbinit.c: In function `rdbopen':
dbinit.c:267: `DB' undeclared (first use in this function)
dbinit.c:267: (Each undeclared identifier is reported only once
dbinit.c:267: for each function it appears in.)
dbinit.c:267: `db' undeclared (first use in this function)
dbinit.c:267: warning: statement with no effect
dbinit.c:270: invalid type argument of `unary *'
dbinit.c:284: warning: assignment makes integer from pointer without a cast
dbinit.c:284: parse error before `PR_FindSymbol'
dbinit.c:286: invalid type argument of `unary *'
dbinit.c: At top level:
dbinit.c:295: parse error before `*'
dbinit.c: In function `db_Copy':
dbinit.c:298: `DBT' undeclared (first use in this function)
dbinit.c:298: parse error before `key'
dbinit.c:299: `src' undeclared (first use in this function)
dbinit.c:299: `key' undeclared (first use in this function)
dbinit.c:299: `data' undeclared (first use in this function)
dbinit.c:299: `R_FIRST' undeclared (first use in this function)
dbinit.c:305: `dest' undeclared (first use in this function)
dbinit.c:305: `R_NOOVERWRITE' undeclared (first use in this function)
dbinit.c:306: `R_NEXT' undeclared (first use in this function)
dbinit.c:297: warning: `ret' might be used uninitialized in this function
make[4]: *** [/usr/src/mozilla/bc-addons/bin/nss/softokn/dbinit.o] Fehler 1
make[3]: *** [libs] Fehler 2
make[2]: *** [libs] Fehler 2
make[1]: *** [tier_95] Fehler 2
make: *** [default] Fehler 2
I use an objdir, disable-debug, enable-optimize
Keywords: mozilla1.0.1
n/m. Works now, after a fresh build. (I wonder, why the fresh build on the other
machine then failed with the same error, but well.)

INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
I'm getting the same build error. I'm using objdir enable-debug disable-optimize.

I've tried with a clean tree. I've tried with the latest release branches of
NSPR, NSS and DBM. I've tried with trunk.

The effect of this is that PSM doesn't get built, so I can't access https sites.

I'm inclined to REOPEN this bug, but since it was initially resolved INVALID, I
was hoping someone could point me to what would fix it.
I have no idea if this is related, but when I make, I get this in the configure
output:

[...]
checking for makedepend... /usr/bin/makedepend
checking for xargs... /usr/bin/xargs
checking for gmake... no
checking for make... /home/vidar/bin/make
/home/vidar/cvs/mozilla/configure: line 4052: test: 3: integer expression expected
/home/vidar/cvs/mozilla/configure: line 4053: test: 80 0: integer expression
expected
checking for X... /home/vidar/cvs/mozilla/dbg-suite/conftestdir
/home/vidar/cvs/mozilla/configure: line 4098: ac_im_incroot=/usr/X11R6/include:
No such file or directory
/home/vidar/cvs/mozilla/configure: line 4098: 0: command not found
libraries /usr/X11R6/lib, headers
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking whether ld has archive extraction flags... yes
[...]

This is a Ubuntu Breezy system. I've been running Ubuntu since it was first
released but my development HDD broke down some days ago, and I just got a new
one. The .mozconfig file I'm using now is an exact copy of the old one I had,
and I see no reason why the build should fail now where it has worked flawlessly
for many months.
I just tried again, completely from scratch (rm -rf'ed everything), following
the build instructions on
<http://developer.mozilla.org/en/docs/Build_Documentation> to the letter, and
I'm getting the same error.
Comparing the command lines locally and on the brad tinderbox, I see that the
command line here is missing -I/[objdir]/dist/include/dbm.

This is the command used locally:
gcc -o /home/vidar/cvs/mozilla/dbg-suite/nss/softokn/dbinit.o -c -g -fPIC
-DLINUX1_2 -Di386 -D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe -DLINUX -Dlinux
-D_POSIX_SOURCE -D_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\"so\"
-DSHLIB_PREFIX=\"lib\" -DSOFTOKEN_LIB_NAME=\"libsoftokn3.so\" -DDEBUG -UNDEBUG
-DDEBUG_vidar -D_REENTRANT -I/home/vidar/cvs/mozilla/dbg-suite/dist/include 
-I/home/vidar/cvs/mozilla/dbg-suite/dist/public/nss
-I/home/vidar/cvs/mozilla/dbg-suite/dist/private/nss
-I/home/vidar/cvs/mozilla/dbg-suite/dist/include
-I/home/vidar/cvs/mozilla/dbg-suite/dist/include/nspr
-I/home/vidar/cvs/mozilla/dbg-suite/dist/public/dbm  dbinit.c

This is the command used on brad (removed
'space/tinderbox/brad/Linux_2.4.29gameboy2-1_Clobber' from all paths to make it
a bit easier to read):
gcc -o /tinderbox-obj/nss/softokn/dbinit.o -c -O2 -fPIC -DLINUX1_2 -Di386
-D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe -DLINUX -Dlinux -D_POSIX_SOURCE
-D_BSD_SOURCE -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\"so\"
-DSHLIB_PREFIX=\"lib\" -DSOFTOKEN_LIB_NAME=\"libsoftokn3.so\" -UDEBUG -DNDEBUG
-D_REENTRANT -I/tinderbox-obj/dist/include  -I/tinderbox-obj/dist/public/nss
-I/tinderbox-obj/dist/private/nss -I/tinderbox-obj/dist/include
-I/tinderbox-obj/dist/include/nspr -I/tinderbox-obj/dist/include/dbm
-I/tinderbox-obj/dist/public/dbm  dbinit.c
/home/vidar/cvs/mozilla/dbg-suite/dist/public/dbm actually doesn't exist at all,
so that explains that include/ doesn't get added, I think ?
Vidar:

NSS can be built as part of Mozilla/Firefox/Thunderbird or
as a standalone component.  In this bug we will only discuss
NSS being built as part of Mozilla/Firefox/Thunderbird.

-I/[objdir]/dist/public/dbm is only used by the standalone
NSS build, so the fact that the directory [objdir]/dist/include/dbm
doesn't exist is to be expected.

-I/[objdir]/dist/include/dbm is added to the NSS compile command
line in mozilla/security/manager/Makefile.in along with
-I/[objdir]/dist/include/nspr:
http://lxr.mozilla.org/seamonkey/source/security/manager/Makefile.in#82

It is strange that you get one but not the other.  We should find
out why.  Could you look for this command line in your build
log?

http://lxr.mozilla.org/seamonkey/source/security/manager/Makefile.in#176

We want to see if the make command line has MOZILLA_INCLUDES="...".
The second paragraph in my previous comment should read:

  -I/[objdir]/dist/public/dbm is only used by the standalone
  NSS build, so the fact that the directory [objdir]/dist/public/dbm
  doesn't exist is to be expected.
This line ?

/usr/bin/make -C /home/vidar/cvs/mozilla/security/nss/lib MAKE="/usr/bin/make
-j1" -j1 CC="gcc"
MOZILLA_INCLUDES="-I/home/vidar/cvs/mozilla/dbg-suite/dist/include/nspr
-I/home/vidar/cvs/mozilla/dbg-suite/dist/include/dbm"
SOURCE_MD_DIR=/home/vidar/cvs/mozilla/dbg-suite/dist
DIST=/home/vidar/cvs/mozilla/dbg-suite/dist MOZILLA_CLIENT=1 NO_MDUPDATE=1
BUILD_TREE=/home/vidar/cvs/mozilla/dbg-suite NS_USE_GCC=1 NS_USE_NATIVE=
Yes, that's the line.  It looks correct.  I don't
know why only the first -I in MOZILLA_INCLUDES is
used.
Alright, I just found out what this is.

/usr/bin/make here is actually a symlink to 'colormake'[1], and it appears that
colormake actually _strips away_ the last argument, hence the /include/ was missing.

As to why it worked before I reinstalled, that's simple:
I installed colormake only a month or so ago, so NSS was already built, and it
changes very rarely, so I've never rebuilt it since I installed colormake.

Not only does it actually _strip away_ arguments, but it also automatically
_truncates_ the output, so that they fit on 80 chars. I found this out earlier
when trying to get the output for comment 6, so I removed this feature from the
colormake.pl script.

If you made a script called 'colormake.pl', would you put features like this in
it, that *changes* the behavior of the original make? /Especially/ if it's not
mentioned in the README at all?

If you can't tell, I'm quite mad at the colormake author.

Now what this does not explain, is why the rest of the build works. I'm not
going to try to figure this out, because the answer probably isn't worth finding.

Terribly sorry for wasting your time, wtchang, chase, et.al.

1: <http://bre.klaki.net/programs/colormake/>
Vidar: no problem.  I'm glad you solved the mystery.
You need to log in before you can comment on or make changes to this bug.