284386 - Build error using gcc4 (oiddata.h, incomplete type)

Status: RESOLVED FIXED

(NSS :: Build, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

gcc -o /home/caillon/builds/mozilla.org/trunk/obj-opt/nss/nsspki/asymmkey.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 -DNSS_3_4_CODE
-UDEBUG -DNDEBUG -D_REENTRANT
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/include 
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/public/nss
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/private/nss
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/include
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/include/nspr
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/include/dbm
-I/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/public/nspr  asymmkey.c
In file included from
/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/private/nss/nsspki1.h:57,
                 from nsspki.h:56,
                 from asymmkey.c:39:
/home/caillon/builds/mozilla.org/trunk/obj-opt/dist/private/nss/oiddata.h:46:
error: array type has incomplete element type
gmake[5]: ***
[/home/caillon/builds/mozilla.org/trunk/obj-opt/nss/nsspki/asymmkey.o] Error 1
gmake[5]: Leaving directory
`/home/caillon/builds/mozilla.org/trunk/mozilla/security/nss/lib/pki'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory
`/home/caillon/builds/mozilla.org/trunk/mozilla/security/nss/lib'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory
`/home/caillon/builds/mozilla.org/trunk/obj-opt/security/manager'
gmake[2]: *** [tier_50] Error 2
gmake[2]: Leaving directory `/home/caillon/builds/mozilla.org/trunk/obj-opt'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/caillon/builds/mozilla.org/trunk/obj-opt'
make: *** [build] Error 2

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch

This seems to fix it.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I think a lot of the code in pki1 is dead code.  
I hate to see us waste effort on dead code.  
Is pki1's OID table ever used?  I doubt it.  
If not, I'd rather see it eliminated than fixed.  

OTOH, one wonders why no other c compiler is bothered by the incomplete
type declaration.  Is this a bug in gcc4?  Is gcc4 demanding a type that
is uneeded.  Does it not support "opaque" types?

Comment 3

[Wan-Teh Chang]

Comment on attachment 176005 [details] [diff] [review]
Patch

This is indeed a strange build failure.
It's hard to understand why no other compilers
complain about this.  If you have spare time
you might want to have the gcc4 team look at
this.  Here is a test case:

----- foo.c -----
extern const struct IncompleteType myArray[];

int foo()
{
    return 1;
}
-----------------

Compile it with "gcc -c foo.c".

This patch is incorrect because oiddata.h
is a public "Stan" header file, so it cannot
include the private "Stan" header file pki1t.h.

I have a better fix: move these two lines

  extern const NSSOID nss_builtin_oids[];
  extern const PRUint32 nss_builtin_oid_count;

from oiddata.h to pki1.h.  See the comment
"fgmr 19990505 moved these here from oiddata.h"
in pki1.h.

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

http://gcc.gnu.org/gcc-4.0/changes.html
* Arrays of incomplete element type are invalid in C. GCC now issues an error
for such arrays. Declarations such as extern struct s x[]; (where struct s  has
not been defined) can be moved after the definition of struct s. Function
parameters declared as arrays of incomplete type can instead be declared as
pointers.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: wtc's suggestion

Comment 6

[Wan-Teh Chang]

Comment on attachment 176304 [details] [diff] [review]
wtc's suggestion

I assume you've tested this patch and
it worked.

Since these two files are generated files,
we also need to update the Perl script that
generates them (oidgen.perl).  I'll take
care of that.

Comment 7

[Wan-Teh Chang]

Attachment: wtc's suggestion v1.1

1. Also updated the Perl script oidgen.perl
that generates oiddata.h and oiddata.c.

2. Fixed an unrelated error in oiddata.c.
One OID (RFC 1327 ucl) was incorrectly encoded
before.  Don't know what happened.

Comment 8

[Wan-Teh Chang]

Attachment: wtc's suggestion v1.2

Removed useless comments.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

>Index: oiddata.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/pki1/oiddata.c,v
>retrieving revision 1.4
>diff -u -r1.4 oiddata.c
>--- oiddata.c	4 Mar 2005 18:30:12 -0000	1.4
>+++ oiddata.c	5 Mar 2005 15:16:07 -0000
>@@ -182,7 +182,7 @@
>     "ucl",
>     "RFC 1327 ucl",
> #endif /* DEBUG */
>-    { "\x09\x92\x26\x86\xe8\xc4\xb5\xbe\x7f", 9 }
>+    { "\x09\x92\x26\x86\xe8\xc4\xb5\xbe\x2c", 9 }

Not sure what this change is about, but the rest looks fine.  r=caillon

Comment 10

[Wan-Teh Chang]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

I've checked in this patch on the NSS trunk
(NSS 3.10).  I checked in the oiddata.c change
separately so that it's clear caillon's code
review does not apply to it.

Nelson, if you have time, you can review my
oiddata.c change.  I found that the OID for
RFC 1327 ucl was incorrectly encoded.  I don't
know what happened.

I verified that the OID for RFC 1327 ucl in
oids.txt is correct.  I also verified that my
hand encoding of that OID matches the output
of oidgen.perl.

Since oiddata.c is not being used in NSS 3.x,
I went ahead and checked in my change.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

Since oiddata.c is not being used in NSS 3.x, I don't think further review of
this source file is necessary.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 286016 has been marked as a duplicate of this bug. ***

Comment 13

[Brian Ryner (not reading)]

Could we possibly get this fix on NSS_CLIENT_TAG?

Comment 14

[Wan-Teh Chang]

Brian: we plan to update NSS_CLIENT_TAG within a
week.  Is that acceptable?

Comment 15

[Brian Ryner (not reading)]

(In reply to comment #14)
> Brian: we plan to update NSS_CLIENT_TAG within a
> week.  Is that acceptable?

Sure, sounds good.

Comment 16

[Wan-Teh Chang]

I just updated the NSS_CLIENT_TAG to coincide with
NSS_3_10_BETA2, which has the fix for this gcc4 build
error.

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 297830 has been marked as a duplicate of this bug. ***

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 299387 has been marked as a duplicate of this bug. ***

Comment 19

[Dave Townsend [:mossop]]

*** Bug 301047 has been marked as a duplicate of this bug. ***

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 301629 has been marked as a duplicate of this bug. ***

Comment 21

[Luis Villa]

When I try to build moz MOZILLA_1_7_BRANCH with gcc 4, I am still getting this
error. Any chance we can get this patch applied there?

Comment 22

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

Let's get this fix on branches, so people who need to compile against gcc4 may
do so.

Comment 23

[Luis Villa]

Reopening this, since it is still not fixed on 1.0.7/1.7.12. All we need is
another review, right, caillon? (Not sure what the procedures are these days...)

Comment 24

[Christopher Aillon (sabbatical, not receiving bugmail)]

Luis, RESOLVED FIXED is for cvs HEAD, which its fixed on.  It has the necessary
reviews, just needs the approval to land on the frozen branches.  When it lands,
the fixed-aviary1.0.x and fixed1.7.x keywords will be applied.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 306588 has been marked as a duplicate of this bug. ***

Comment 26

[Daniel Veditz [:dveditz]]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

build fix ok for branches.

Comment 27

[Ali Sobhi]

(In reply to comment #26)
> (From update of attachment 176366 [details] [diff] [review] [edit])
> build fix ok for branches.
> 

I just started a JHBUILD for Gnome 2.12 and it uses the following command to get
mozilla

cvs -d :pserver:[e-mail]:/cvsroot -q -z 3 co -r
MOZILLA_1_7_BRANCH -P  mozilla/client.mk mozilla/build/unix/modules.mk
mozilla/build/unix/uniq.pl

make[1]: Entering directory `/opt/lap/g2src/cvs/2.12/src'

cvs -d :pserver:[e-mail]:/cvsroot -q -z 3 co -P -r
MOZILLA_1_7_BRANCH mozilla/nsprpub

=======
the build process breaks with the following error (on Fedora Core 4 with GCC 4)

../../../../dist/private/nss/oiddata.h:46: error: array type has incomplete
element type
gmake[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/asymmkey.o] Error 1


What do I need to do to get the "fixes" incorporated in this branch?

Comment 28

[Christian Kirbach]

See Comment #27

Apparently this patch has not landed in MOZILLA_1_7_BRANCH, I still get the error.

Christopher, will you reopen the report, please?

Comment 29

[Christian Kirbach]

This is *the only* gcc4 blocker.

I strongy suggest it is applied to the 1.7 branch.

Comment 30

[Wan-Teh Chang]

*** Bug 305752 has been marked as a duplicate of this bug. ***

Comment 31

[Wan-Teh Chang]

Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

We forgot to check in this patch when we got
our aviary1.0.7 and mozilla1.7.12 approvals.
I am requesting new approvals for the
AVIARY_1_0_1_20050124_BRANCH and
MOZILLA_1_7_BRANCH.

This is a build bustage fix.  Without this
patch, we can't build with GCC 4.

Comment 32

[Daniel Veditz [:dveditz]]

a=dveditz for drivers on the old branches. Please check in soon.

Comment 33

[Wan-Teh Chang]

I checked in the patch on the AVIARY_1_0_1_20050124_BRANCH and
MOZILLA_1_7_BRANCH.