Closed Bug 284386 Opened 15 years ago Closed 15 years ago

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

Categories

(NSS :: Build, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: caillon, Assigned: caillon)

References

Details

(Keywords: fixed-aviary1.0.8, fixed1.7.13)

Attachments

(1 file, 3 obsolete files)

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
Attached patch Patch (obsolete) — Splinter Review
This seems to fix it.
Attachment #176005 - Flags: review?(wtchang)
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 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.
Attachment #176005 - Flags: review?(wtchang) → review-
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.
Attached patch wtc's suggestion (obsolete) — Splinter Review
Attachment #176005 - Attachment is obsolete: true
Attachment #176304 - Flags: review?(wtchang)
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.
Attachment #176304 - Flags: review?(wtchang) → review+
Attached patch wtc's suggestion v1.1 (obsolete) — Splinter Review
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.
Attachment #176304 - Attachment is obsolete: true
Attachment #176354 - Flags: review?(caillon)
Removed useless comments.
Attachment #176354 - Attachment is obsolete: true
Attachment #176366 - Flags: review?(caillon)
Attachment #176354 - Flags: review?(caillon)
Attachment #176366 - Attachment description: 176354: wtc's suggestion v1.2 → wtc's suggestion v1.2
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
Attachment #176366 - Flags: review?(caillon) → review+
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.
Attachment #176366 - Flags: superreview?(nelson)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10
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.
Attachment #176366 - Flags: superreview?(nelson)
*** Bug 286016 has been marked as a duplicate of this bug. ***
Could we possibly get this fix on NSS_CLIENT_TAG?
Brian: we plan to update NSS_CLIENT_TAG within a
week.  Is that acceptable?
(In reply to comment #14)
> Brian: we plan to update NSS_CLIENT_TAG within a
> week.  Is that acceptable?

Sure, sounds good.
I just updated the NSS_CLIENT_TAG to coincide with
NSS_3_10_BETA2, which has the fix for this gcc4 build
error.
*** Bug 297830 has been marked as a duplicate of this bug. ***
*** Bug 299387 has been marked as a duplicate of this bug. ***
*** Bug 301047 has been marked as a duplicate of this bug. ***
Summary: Build error using gcc4 → Build error using gcc4 (oiddata.h, incomplete type)
*** Bug 301629 has been marked as a duplicate of this bug. ***
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 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.
Attachment #176366 - Flags: approval1.7.12?
Attachment #176366 - Flags: approval-aviary1.0.7?
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...)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
*** Bug 306588 has been marked as a duplicate of this bug. ***
Comment on attachment 176366 [details] [diff] [review]
wtc's suggestion v1.2

build fix ok for branches.
Attachment #176366 - Flags: approval1.7.12?
Attachment #176366 - Flags: approval1.7.12+
Attachment #176366 - Flags: approval-aviary1.0.7?
Attachment #176366 - Flags: approval-aviary1.0.7+
(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:anonymous@cvs-mirror.mozilla.org:/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:anonymous@cvs-mirror.mozilla.org:/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?
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?
This is *the only* gcc4 blocker.

I strongy suggest it is applied to the 1.7 branch.
*** Bug 305752 has been marked as a duplicate of this bug. ***
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.
Attachment #176366 - Flags: approval1.7.13?
Attachment #176366 - Flags: approval1.7.13+
Attachment #176366 - Flags: approval-aviary1.0.8?
Attachment #176366 - Flags: approval-aviary1.0.8+
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
Attachment #176366 - Flags: approval1.7.13?
Attachment #176366 - Flags: approval1.7.13+
Attachment #176366 - Flags: approval-aviary1.0.8?
Attachment #176366 - Flags: approval-aviary1.0.8+
a=dveditz for drivers on the old branches. Please check in soon.
I checked in the patch on the AVIARY_1_0_1_20050124_BRANCH and
MOZILLA_1_7_BRANCH.
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
You need to log in before you can comment on or make changes to this bug.