Closed Bug 487162 Opened 17 years ago Closed 17 years ago

ckfw/capi build failure on windows

Categories

(NSS :: Libraries, defect, P2)

3.12.3
x86
Windows XP
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.4

People

(Reporter: KaiE, Assigned: rrelyea)

References

Details

Attachments

(1 file)

When landing NSS 3.12.3 rc 0 we got a build failure when building Mozilla. Reason is that directory ckfw/capi only gets built in the Mozilla client configuration. As a quick solution I disabled building capi, r=nelson We need to fix the compiler error in staticobj.c and re-enable the build.
Build log: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239070965.1239072544.11625.gz Build failure: e:/builds/moz2_slave/mozilla-central-win32-unittest/build/security/nss/lib/ckfw/capi/staticobj.c(71) : error C4047: 'initializing' : 'CK_OBJECT_CLASS' differs in levels of indirection from 'void *'
Can we change ckfw/Makefile to build capi by default when doing NSS builds?
The last few lines of lib/ckfw/cpi/staticobj.c are > ckcapiInternalObject nss_ckcapi_data[] = { > { ckcapiRaw, { 5, nss_ckcapi_types_1, nss_ckcapi_items_1} , {((void *)0)} }, > }; > > const PRUint32 nss_ckcapi_nObjects = 1; The type ckcapiInternalObject contains a union. The code above is trying to initialize one of the members of that union with a static initializer. That's a no-no.
Assignee: nobody → rrelyea
OS: Linux → Windows XP
IMO, it doesn't belong in NSS. It uses NSS. It uses lib/ckfw. It's not part of either one. It doesn't belong under lib/ckfw any more than programs that use libc belong in the libc source tree.
lib/ckfw/Makefile contains these lines: > ifdef MOZILLA_CLIENT > NSS_BUILD_CAPI = 1 > endif But NONE of the NSS team members builds routinely with MOZILLA_CLIENT defined. So, when Mozilla takes a snapshot of NSS, they find themselves building things that the NSS does not build and has not build for months, if ever. I believe Kai removed those lines from Mozilla's snapshot of the Makefile. (That was my suggestion, and I have r+ to that patch, sight unseen. :) I'd say we should do that in the CVS tree, too.
The code was always wrong, I believe. NSS just catches it now with its more strict error checking during compilation. I believe the only portable solutions to this are: a) stop using a static initializer, or b) change this object (structure) type to remove all unions. I'll let Bob carry it from here.
I was mistaken about the cause of the error. It wasn't the initialization of the union. It was the attempt to initialize a member of type CK_OBJECT_CLASS with the value {NULL}. This patch fixes it, and makes MSVC happy. I think think it's an error to use a static initializer for a union. But the immediate issue is to pacify MSVC.
Attachment #371375 - Flags: review?(rrelyea)
Blocks: 486182
Target Milestone: --- → 3.12.4
(In reply to comment #5) > lib/ckfw/Makefile contains these lines: > > > ifdef MOZILLA_CLIENT > > NSS_BUILD_CAPI = 1 > > endif > > ... > > I believe Kai removed those lines from Mozilla's snapshot of the Makefile. yes
(In reply to comment #7) >I think think it's an error to use a static initializer for a union. My hazy memory suggests that you initialise it as if it was its first member.
Attachment #371375 - Flags: review?(rrelyea) → review+
Checking in staticobj.c; new revision: 1.3; previous revision: 1.2
Status: NEW → RESOLVED
Closed: 17 years ago
Priority: -- → P2
Resolution: --- → FIXED
Blocks: 487712
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: