158649 - compile error in cdbhdl.h / dbinit.c

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Ben Bucksch (:BenB)]

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

Comment 1

[Ben Bucksch (:BenB)]

I use an objdir, disable-debug, enable-optimize

Comment 2

[Ben Bucksch (:BenB)]

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.

Comment 3

[Vidar Haarr (not reading bugmail)]

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.

Comment 4

[Vidar Haarr (not reading bugmail)]

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.

Comment 5

[Vidar Haarr (not reading bugmail)]

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.

Comment 6

[Vidar Haarr (not reading bugmail)]

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

Comment 7

[Vidar Haarr (not reading bugmail)]

/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 ?

Comment 8

[Wan-Teh Chang]

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="...".

Comment 9

[Wan-Teh Chang]

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.

Comment 10

[Vidar Haarr (not reading bugmail)]

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=

Comment 11

[Wan-Teh Chang]

Yes, that's the line.  It looks correct.  I don't
know why only the first -I in MOZILLA_INCLUDES is
used.

Comment 12

[Vidar Haarr (not reading bugmail)]

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/>

Comment 13

[Wan-Teh Chang]

Vidar: no problem.  I'm glad you solved the mystery.