62855 - NSS build for OS/2

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[jhp (no longer active)]

File changes necessary to get NSS to build on the trunk for OS/2.  
This bug depends on bug 60912.

Comment 1

[jhp (no longer active)]

Attachment: OS/2 patch for files in nss and coreconf

Comment 2

[Wan-Teh Chang]

Assigned the bug to relyea.

Comment 3

[jhp (no longer active)]

Attachment: latest patch

Comment 4

[jhp (no longer active)]

Attachment: updates os2.mk and rules.mk

Comment 5

[jhp (no longer active)]

In the above patch, I updates security/coreconf/OS2.mk and 
security/coreconf/rules.mk, in order to properly create DLLs 
(specifically nssckbi.dll, the root certs library).

Comment 6

[Mike Kaply [:mkaply]]

salsero suggested I reassign this bug to you.

These are OS/2 changes to get NSS building on the tip.

We'd really like to get them in.

I'll even check them in if that is possible.

Comment 7

[Robert Relyea]

A couple of comments:
 1) Wan-Teh, do we still need PR_CALLBACK? If so do we have platforms that
require the current tree order. I seem to remember PR_CALLBACK was to let win16
work. Does OS/2 really need to define it to allow callbacks across .DLL's?
 2) Could one of the OS/2 team look at the new symbol restriction code used for
nss3.dll ssl3.dll and smime3.dll (in mozilla/security/nss/lib/{nss,ssl,smime}
and see if it's appropriate too make these work for OS/2 as well (there are
changes too rules.mk in coreconf as well).

The rest of the changes look good. I especially like the extra entropy in
os2rand.c now.

bob

Comment 8

[Mike Kaply [:mkaply]]

OS/2 does still require PR_CALLBACK. Our compiler uses different calling 
convention for C++ vs. C and there is no way to override it.

PR_CALLBACK is designed for any platform that needs to specify calling 
convention when executing callbacks.

What do you mean by "current tree order"?

Comment 9

[Wan-Teh Chang]

Javier: do I only need to review the last patch?
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23187)

Comment 10

[jhp (no longer active)]

Attachment: updated some files for EMX

Comment 11

[jhp (no longer active)]

Wan-Teh Chang:
Each patch supercedes the previous one.  Would you rather I add a 
patch for each file?

Comment 12

[jhp (no longer active)]

Wan-Teh Chang:

In response to your mail:

> Another question: in mozilla/security/nss/lib/fortcrypt/swfort/swutl.c,
> could you delete #include <sys/stat.h>
> and see if you can still compile under VACPP?
if i remove it, i get this error:
	error: "struct stat" is undefined

> Similarly in mozilla/security/nss/lib/util/os2_rand.c,
> do you need to include <sys/stat.h> to compile under
> VACPP?
also:
	error: "struct stat" is undefined

> Finally, in mozilla/security/nss/cmd/selfserv/selfserv.c,
> I'm curious as to what the <Process.h> header file is for.
> Do you need it for getpid()?
yes, needed for getpid()

Comment 13

[Wan-Teh Chang]

Javier: one big patch file is fine.

So <sys/stat.h> works for both EMX and VACPP?

Comment 14

[jhp (no longer active)]

yes, we've got one person building EMX, and he says that using <sys/stat.h>
works for him, too.

Also, I noticed in psm/server that there is now a psmmain.c and a main.cpp. 
However, trying to compile the two results in link errors since they both
declare several of the same functions.  If I remove psmmain.c from the
manifest.mn, then it builds and runs fine.  What is the purpose of psmmain.c?

Comment 15

[Wan-Teh Chang]

OK, I've checked in the equivalent of your latest patch
on both the tip and the NSS_3_1_BRANCH of NSS.

Javier, could you try it out?  You need to manually modify
mozilla/client.mk and change "NSS_CLIENT_TAG" to "NSS_3_1_BRANCH".

Comment 16

[Wan-Teh Chang]

Javier, regarding your question about psmmain.c and main.cpp
in psm/server, please refer to Bug #64650, especially the
comments from Jim Dunn at 2001-01-17 11:56.

Comment 17

[jhp (no longer active)]

Attachment: new coreconf/rules.mk

Comment 18

[jhp (no longer active)]

Wan-Teh Chang, I changed rules.mk, adding a rule to handle the 
building of *.cpp files in order to properly handle bug #64650.  Could 
you also check this in?  Also, I am in the process of trying out the 
NSS_3_1_BRANCH.  I'll let you know. Thanks

Comment 19

[Wan-Teh Chang]

Javier, I checked in your patch for coreconf/rules.mk (the .cpp rule)
on the tip and the NSS_3_1_BRANCH.

Comment 20

[jhp (no longer active)]

Attachment: changes to properly build nssckbi

Comment 21

[jhp (no longer active)]

don't know how i missed it earlier, but I ran into a build break in 
ckfw/builtins.  For OS/2, no import library was getting built, so I 
changed some of the coreconf files, as well as the Makefile in that 
directory.  Seems to build fine now.  This is using the NSS_3_1_BRANCH 
tag.  Thanks.

Comment 22

[Wan-Teh Chang]

Javier: for nssckbi.dll, we do not need to build the
import library because nssckbi.dll is always loaded
dynamically.  Given this, is your patch still necessary?

Comment 23

[jhp (no longer active)]

I realize that, but i figured it would be best to fix the root problem 
in case the import library was ever needed in the future.  If this it 
too much trouble for a library that isn't used, then I can just set 
IMPORT_LIBRARY = {null} and not worry about the changes to coreconf.  
Which do you recommend?

Comment 24

[Wan-Teh Chang]

Javier: I figured out why your build failed in ckfw/builtins
and checked in a fix on NSS_3_1_BRANCH.  Your makefile rule
to build import libraries will be needed by NSS 3.2, but for
NSS_3_1_BRANCH we can do without it.  Please update your NSS
tree (cvs tag NSS_3_1_BRANCH) and try again.  Thanks.

I will check in your import library rule on the tip of NSS
if I have time, as it will be needed when you port NSS 3.2
to OS/2.

Comment 25

[jhp (no longer active)]

Thanks, everything seems to work well (for now!)...

Comment 26

[Wan-Teh Chang]

Thanks.  I'm marking this bug as fixed.  I will ask
the PSM team to move the NSS_CLIENT_TAG on the modified
files.

Comment 27

[Wan-Teh Chang]

By the way, I checked in your OS/2 import library makefile
rule on the tip of NSS.

Comment 28

[jhp (no longer active)]

verified