98349 - Convert Mac build to CW7 with XML projects

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Conrad Carlen (not reading bugmail)]

In June, I made a branch which did the build using CW7 EA, XML projects, and no
ToolServer. At this point, the branch is probably too old to merge and
significant changes have been made to the build scripts in the meanwhile.

I'll use this bug as a placeholder for various patches:
(1) Changes to the build scripts which can be checked before the switch to
automatically update CW projects.
(2) Changes to the code which allow it to compile with the new compiler (which
is more strict) but should compile with the current compiler as well.

Comment 1

[Conrad Carlen (not reading bugmail)]

-> after 6.2 RTM

Comment 2

[Conrad Carlen (not reading bugmail)]

Attachment: In progress build script changes

Comment 3

[Conrad Carlen (not reading bugmail)]

Putting these here for safe-keeping and for potential usefulness to others.
These changes, by having build flags UPDATE_PROJECTS and BUILD_PROJCTS, allow
you to, by defining UPDATE_PROJECTS in build prefs, to go through the tree and
automatically update all projects to the latest CW. This was possible by hacking
CodeWarriorLib.pm to have an open_project routine which takes a param telling
whether to update the project on opening it. open_project, since it returns a
reference to the project, has other uses as well. If we had a build_target
routine, the IDL projects could be built by doing:

$my(p) = open_project()
build_target($p, headers)
build_target($p, xpt)
close_project($p)

Then, without doing the "leave projects open" bit, IDL projects would probably
build faster this way.
 

Comment 4

[Conrad Carlen (not reading bugmail)]

Plan of attack:

1. Use the build script patches here to automatically update all projects in the
tree to Pro 7. (Done)
2. Get the build to work. At this point, I'll post a tree-wide patch here and an
archive of projects which needed manual changes. (In progess  today)
3. Use the build scripts to export all of the now working .mcp projects to XML
4. Check in the XML files
5. Flip the switch in the build scripts.

Comment 5

[Andrew Thompson]

Don't forget to look at some of my old CW6 bugs if you find problems. Search the 
summary field for CW6 and follow the dependencies, including the "fixed" ones. 
(many of them were WONTFIX as we skipped CW6 and some assumed there wouldn't be 
the same problems in 7. Given most of the issues where ANSI compliance, I think 
that's optimisitic)

Now would be a good time to fix bug 40013 and 40100 too, if you're cleaning up 
the build system. Actually 40100 is a blocker for this as CW7 won't build because 
of it.

Might save you some time...

Comment 6

[Conrad Carlen (not reading bugmail)]

This bug obsoletes bug 40100 and bug 53679. Both of those issues are being dealt
with here. I suggested those bugs be closed but I'll clear the dependency
anyway. Also, bug 40013 has been incorporated (thanks!).

Comment 7

[Andrew Thompson]

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

Comment 8

[Andrew Thompson]

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

Comment 9

[Andrew Thompson]

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

Comment 10

[Conrad Carlen (not reading bugmail)]

How sad - I have a patch for the whole tree but bugzilla is not letting me post
it right now. I'll try in the morning.

Comment 11

[Conrad Carlen (not reading bugmail)]

Attachment: changed projects

Comment 12

[Conrad Carlen (not reading bugmail)]

Attachment: tree-wide patch to text files

Comment 13

[Conrad Carlen (not reading bugmail)]

Attachment: changed projects

Comment 14

[Conrad Carlen (not reading bugmail)]

Here's the list of changed projects:

xpidl.mcp
Interface.mcp
MemAllocator.mco
NSRuntime.mcp
NSStdLib.mcp
xpcomPPC.mcp
gfx.mcp
widget.mcp
PowerPlant.mcp
PPBrowser.mcp

I have built (under OS X) and run the CarbonDebug build.

Still to do:
(1) the three other builds (classic, opt, etc.)
(2) churn out the XML files - easy and automated
(3) check in the 210 XML projects 

Comment 15

[Peter Van der Beken [:peterv]]

Conrad, while you're touching NSRuntime.mcp, could you fix the profiling targets
too? They're currently misnamed, they're named NSRuntime[Carbon]Profil.shlb but
they generate a debug library. I suggest we name them
NSRuntime[Carbon]ProfileDebug.shlb and add optimized targets too.

Comment 16

[Conrad Carlen (not reading bugmail)]

I think the reason they're misnamed, or the names are truncated, is because the
31 char file name limit. It should be possible to have a target name > 31 chars
though(?) I'll check it out.

Comment 17

[Andrew Thompson]

Comment on attachment 53251 [details] [diff] [review]
tree-wide patch to text files

Conrad: one hunk fails in object.c, I looked and its trying to change the CVS tag embeded in the file. I take it this was accidental?

Comment 18

[Andrew Thompson]

Problems with this patch:

1/ From the CodeWarrior SDK library notes:

"The Mac OS shared libraries in this folder are provided for linking purposes
only. The actual library implementations are merged into the 4.2.5 IDE.  So,
when testing your plugins you should not copy the MWMacOSCOM.shlb or
PluginLib4.shlb into your CodeWarrior installation.  Likewise, you should not
merge these libraries into your plugins."

I think this means we ought to alter out build instructions to tell people to 
leave the "(CodeWarrior SDK)" folder where it is (in the top level of the 
CodeWarrior install) and simply add Compiler Relative access paths for the 
"libraries" and "headers" folders to xpidl.mcp.

AFAICT the Panels, Linker and Compiler targets need to be changed.

2/ The project still includes PluginLib4, which no longer exists. Should be 
linking against instead PluginLib4.shlb I think...

Comment 19

[Andrew Thompson]

:( Currently blowing up in MemAllocator... probably fairly simple to fix, will 
try later:

Error   : ambiguous access to overloaded function 
'malloc(unsigned long)'
'std::malloc(unsigned long)'
nsAllocatorManager.cp line 716   newBlock = ::malloc(newSize);

Error   : ambiguous access to overloaded function 
'free(void *)'
'std::free(void *)'
nsAllocatorManager.cp line 723   ::free(block);

Error   : ambiguous access to overloaded function 
'malloc(unsigned long)'
'std::malloc(unsigned long)'
nsAllocatorManager.cp line 734   void    *newBlock = ::malloc(space);

Comment 20

[Andrew Thompson]

Heh, well here's the patch I used to fix this bug *last* time I hit it, with 
CodeWarrior 6 :) Conrad... comments?

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15586

Comment 21

[Andrew Thompson]

Ah crap! I just realised I was building Classic not Carbon (macperl saw a 
different prefs file when I'm booted into OS X vs. OS 9 - fixed that one)

So all of the stuff above applies to Classic builds with CodeWarrior 7 - which of 
course Conrad hasn't done yet...

Comment 22

[Andrew Thompson]

Carbon is going much better, but I have issues with PPBrowser - I've done all the 
usual stuff like deleting project Data folders for PPBrowser.mcp and 
Powerplant.mcp and rebuilding them. Any ideas?

Link Error   : undefined 'LTimerTaskFunctor::~LTimerTaskFunctor()' (descriptor)
Referenced from '@2291' in PowerPlantCarbonDebug.o

Link Error   : undefined 'LTimerTaskFunctor::~LTimerTaskFunctor()' (code)
Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point&
,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o

Link Error   : undefined 'LTimerTask::SetUserData(void*)' (code)
Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point&
,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o

Link Error   : undefined 
'LTimerTaskFunctor::LTimerTaskFunctor(OpaqueEventLoopRef*,double,double,void (*
)(LTimerTask*))' (code)
Referenced from 'UMouseTracking::TrackMouseDownWithAction(OpaqueGrafPtr*,Point&
,unsigned short&,void (*)(void*),unsigned long,void*)' in PowerPlantCarbonDebug.o

Comment 23

[Conrad Carlen (not reading bugmail)]

Add the files LTimerTask.cp and LTimerTaskFunctor.cp to
lib/mac/PowerPlant/PowerPlant.mcp. They go in the "Support Classes" section.

Comment 24

[Andrew Thompson]

With that change, and the stuff for the CodeWarrior SDK I mentioned it builds for 
me!

Debug build seems to be running pretty well. Kudos Conrad.

Comment 25

[Conrad Carlen (not reading bugmail)]

> With that change, and the stuff for the CodeWarrior SDK I mentioned

I'm still not clear why you had to change that. I used the same plugin SDK we've
been using, linked the tools with CarbonLib instead of InterfaceLib, and
everything was fine. 

Comment 26

[Andrew Thompson]

Well, the very specific problem I have is that "PluginLib4" no longer exists in 
the 7.0 (or 6.0) SDK - there are 2 files "PluginLib4.lib" and "PluginLib4.shlb". 
of these, only "PluginLib4.shlb" will work, if you try to include 
"PluginLib4.lib" in the Carbon build one gets an "Illegal object data" error (or 
words to that effect).

The other comment is less direct - the notes with the 6.X/7.X CodeWarrior SDK 
imply one should not copy the SDk folder into the standard Access Paths, rather 
one should add custom Access Paths to your project so as to use the SDK from the 
location it is installed. I'm not sure it really matters, but it occurs to me 
that we could simplify our build instructions, which currently specify that the 
SDK must be manually installed with CodeWarrior pro5, by instead editing the 
xpidl.mcp project to refer to the location where the CodeWarrior SDK is installed 
by default with Pro7. 

In other woulds it would removes a step from the "setting up a build environment" 
instructions, and it may be more in line with what Metrowerks recommend.

Comment 27

[Conrad Carlen (not reading bugmail)]

> In other woulds it would removes a step from the "setting up a build
> environment" instructions, and it may be more in line with what Metrowerks
> recommend.

I'm all for that. BTW, I used the old plugin SDK that we're using for CW5. While
that worked fine, now would be the time to upgrade to a newer SDK. Does the
plugin SDK come on the CW7 CD (which  I don't have yet)?

Comment 28

[Andrew Thompson]

Yes, its on the CD. I don't recall specifically asking for it to be installed, so 
I think its installed by default (though obv. someone should check). Seems to be 
working fine for me with the changes I suggested.

Comment 29

[Conrad Carlen (not reading bugmail)]

The patch is old now but here's how to use it on a clean tree:

Apply the tree-wide patch
Put UPDATE_PROJECTS 1 and BUILD_PROJECTS 0 in your build prefs.
Run the build - this will just update all the projects to CW7
Replace projects with the ones in attachment 53252 [details] - this is for projects which
required more change than updating
Put UPDATE_PROJECTS 0 and BUILD_PROJECTS 1 in your build prefs
Run the build - this will build it.

Comment 30

[Conrad Carlen (not reading bugmail)]

Mass move to 0.9.7

Comment 31

[Jon Granrose]

QA to jj

Comment 32

[Andrew Thompson]

Conrad - this is busted again - someone made a new target "StubsCarbon" in 
NSStdLib, which your version doesn't have.

This uses NSStdLibCarbon.exp rather than NSStdlib.exp, so your patch will need 
updating to get both files again.

I'll see if I can work around this, but my experience is I can't figure this .exp 
stuff out for myself -> can you help please?

Comment 33

[Conrad Carlen (not reading bugmail)]

The reason mine didn't have StubsCarbon is that there will probably be no
separate StubsCarbon target for StdLibs. The reason we have two now is they're
made from two different src bases, so the symbols, and therefor the .exp files
had to be different. Hopefully, the differences between Carbon & Classic will
only be on symbols which are not exported. I'll know soon if you can wait.

I'm going to do the final pass on this and check it in soon.

As far as making .exp files, here's what I did:
* I turned this on in the prefix file +#define _MSL_IMP_EXP __declspec(export)
and set the linker to export using #pragma. Every symbol in the Std Libs which
is *meant* to be exported is declared with this macro.
* Built the lib as a shared lib. This required some other libs to be already
built so it would link.
* I used the MPW tool DumpPef on that shared lib and dumped the export list.
That was what went into the .exp file. I trimmed of the leftmost column from
what DumpPef gave me and sorted the output.

Doing this, you end up with a much smaller .exp list which only exports what MSL
means to export. The rest of the .exp file (things  like MoreFiles), were just
copied from the old file.

Comment 34

[Andrew Thompson]

I'm obviously doing something wrong, because when I did the dump pef, I got a 
strange set of symbols - well there's pretty normal, but nothing like the files 
in CVS. I attached one for an exmaple.

I made this by building NSStdLibCarbonDebug.shlb
Do you have to pass any arguments to DumpPef? Can you think of anything you 
missed in your instructions.

Comment 35

[Andrew Thompson]

Attachment: Example of what I get from DumpPEF (don't use this if you're trying to build)

Comment 36

[Conrad Carlen (not reading bugmail)]

That looks about right. It shouldn't look anything like what's in the tree now.
In addition to those symbols, you have to include those from other libs that are
linked into nsStdLib. Again, there may not be a separate target for Carbon when
all is said and done. 

Comment 37

[Andrew Thompson]

Hrm, it seems every time I update I get further away from a tree that builds.

conrad - can you post your NSStdLib.mcp and corresponding .exp files on this bug
please?

It'll be great if this is all checked in by Dec-03, but I'd like to be able to
build now if possible, rather than lose a week.

Cheers.

Comment 38

[Conrad Carlen (not reading bugmail)]

I got both Carbon & Classic building on a tree pulled two days ago. Now, as long
as I can keep this tree current with the tip for a few more days, we should be good.

I ran into a problem on Classic. When building Interface.mcp, somehow
ContextualMenu was not set to merge with output(?). I made it so and then, on
linking, CW said it encountered an unexpected EOF on the file ContextualMenu.
The only workaround was replace that file in CW7 with another copy from Fizzilla
Tools. I installed CW7 directly from the CD but it appears that that file is
corrupted. Maybe it's my hard drive?

Can somebody else try this:
(1) Open up Interface.mcp with CW7
(2) Check that, after the conversion, ContextualMenu is set to merge w/output
(3) Build the project and see if it links

Comment 39

[Mike Pinkerton (not reading bugmail)]

this happens off and on. i'd thought we'd put it behind us. i never did figure
out if it was a packaging problem on apple's end or what. i'll try the test
later today.

Comment 40

[Conrad Carlen (not reading bugmail)]

Attachment: patch for nspr

This is the whole patch for nspr and will need to be checked in by somebody
with access. It includes the XML project as an added file so, after applying
this, that should do it for nspr.

Comment 41

[Conrad Carlen (not reading bugmail)]

Attachment: patch for security

Needs to be checked in by somebody with access. Since there are a number of new
XML projects, they're in an upcoming attachment. As new files in a patch, this
diff would have been huge.

Comment 42

[Conrad Carlen (not reading bugmail)]

CC'ing javi for help with security checkin.

Comment 43

[Simon Fraser [no longer active]]

wtc will have to review some of the changes in attachment 59950 [details] [diff] [review], notably:

Index: nsprpub/pr/src/io/prfile.c
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/pr/src/io/prfile.c,v
retrieving revision 3.36
diff -u -2 -r3.36 prfile.c
--- prfile.c    2001/06/04 04:29:34     3.36
+++ prfile.c    2001/11/30 23:49:19
@@ -204,5 +204,5 @@
 }
 
-static PRStatus PR_CALLBACK FileInfo(PRFileDesc *fd, PRFileInfo *info)
+static PRStatus PR_CALLBACK FileGetInfo(PRFileDesc *fd, PRFileInfo *info)
 {
        PRInt32 rv;
@@ -215,5 +215,5 @@
 }
 
-static PRStatus PR_CALLBACK FileInfo64(PRFileDesc *fd, PRFileInfo64 *info)
+static PRStatus PR_CALLBACK FileGetInfo64(PRFileDesc *fd, PRFileInfo64 *info)
 {
 #ifdef XP_MAC
@@ -277,6 +277,6 @@
     FileSeek,
     FileSeek64,
-    FileInfo,
-    FileInfo64,
+    FileGetInfo,
+    FileGetInfo64,
     (PRWritevFN)_PR_InvalidInt,                
     (PRConnectFN)_PR_InvalidStatus,            

I welcome this change; 'FileInfo' is a struct in the Mac headers, and this has 
bitten me before.

The other changes look good to me.

Comment 44

[Conrad Carlen (not reading bugmail)]

Attachment: new xml projects for security

This is a ZIP of all the new XML projects for security. Each XXX.xml goes
directly beside its corresponding XXX.mcp. When the new files are checked in,
all the .mcp files get removed.

Comment 45

[Conrad Carlen (not reading bugmail)]

Attachment: patch for the rest of seamonkey

Here's the patch I can check in.

Comment 46

[Conrad Carlen (not reading bugmail)]

Attachment: non-functional but easier to review MozillaBuildList.pm

In the actual patch for MozillaBuildList.pm, every occurance of .mcp changes to
.xml which makes it hard to see what really changed which wasn't much. For this
file, I just turned .xml back to .mcp.

Comment 47

[Conrad Carlen (not reading bugmail)]

Troubles today. I doubt this will make it by Monday - probably Wedsnesday. Once
it's reviewed, it needs testing on somebody else's machine. JJ, if you can pull
a branch, let me know - I'll make one tomorrow. Also, the problem in comment #38
is still unknown.

Comment 48

[Conrad Carlen (not reading bugmail)]

Patrick, I need your help on something with the MRJ Plugin. See this bit from
the build script:

 	    # Build MRJPlugin.jar (if Java tools exist)
 	    my($linker_path) = GetCodeWarriorRelativePath("CodeWarrior
Plugins:Linkers:Java Linker");
 	    if (-e $linker_path) {
 	        print("CodeWarrior Java tools detected, building MRJPlugin.jar.\n");
-
        BuildProject($project_path, "MRJPlugin.jar");
+
        BuildProject($plugin_path . "MRJPlugin.xml", "MRJPlugin.jar");
 	    }

With the standard install of CW7, the Java tools exist, so it will build
MRJPlugin.jar. This has some problems:
(1) MRJPlugin.jar is checked into the tree - so why are we trying to built it?
(2) If we do build it, the MRJPlugin.jar target in MRJPlugin.xml is has
problems. The output for the target has some default name (not MRJPlugin.jar)
That's why I updated the .xml project - so at least the output name was right.
(3) The MRJPlugin.jar target has Classic System Folder relative access paths
which isn't going to work when building under OS X.

This needs to be figured out but, in the meanwhile, since MRJPlugin.jar is
checked into the tree, I should comment out the part in the build script that
would try and build it.

Comment 49

[Conrad Carlen (not reading bugmail)]

javi - can you r= the security changes. Pretty harmless - just some const params
which were being assigned to non-const locals. CW7 doesn't take that.

wtc - can you r= the nspr part. Some symbols had to be renamed to avoid name
conflicts with Mac headers.

Then, I just need somebody to do an overall r= of the rest, assuming Simon does
the sr=. Anybody?

Comment 50

[Javier Delgadillo]

I've asked wtc to get someone from the NSS to review the security changes since
they're all part of the NSS tree.

Comment 51

[Patrick C. Beard]

On Saturday, December 1, 2001, at 11:03  AM, [e-mail] wrote:
> Patrick, I need your help on something with the MRJ Plugin. See this bit from
> the build script:
> 
>  	    # Build MRJPlugin.jar (if Java tools exist)
>  	    my($linker_path) = GetCodeWarriorRelativePath("CodeWarrior
> Plugins:Linkers:Java Linker");
>  	    if (-e $linker_path) {
>  	        print("CodeWarrior Java tools detected, building MRJPlugin.jar.\n");
> -
>         BuildProject($project_path, "MRJPlugin.jar");
> +
>         BuildProject($plugin_path . "MRJPlugin.xml", "MRJPlugin.jar");
>  	    }
> 
> With the standard install of CW7, the Java tools exist, so it will build
> MRJPlugin.jar. This has some problems:
> (1) MRJPlugin.jar is checked into the tree - so why are we trying to built it?

For obvious reasons, we should build it so that is part of tinderbox.
Developers have been resistant to having Java development tools in their
default CodeWarrior installation, so we checked it in to at least have
the bits available. I would like to cvs remove MRJPlugin.jar and have
everybody build it if possible. We should always use a stock
installation of CodeWarrior as possible.

> (2) If we do build it, the MRJPlugin.jar target in MRJPlugin.xml is has
> problems. The output for the target has some default name (not MRJPlugin.jar)
> That's why I updated the .xml project - so at least the output name was right.

That's fine.

(3) The MRJPlugin.jar target has Classic System Folder relative access paths
which isn't going to work when building under OS X.

True, however this MRJPlugin project is only built for classic Mac OS
8/9. I can fix this by using the classes.zip or classes.jar that comes
with CW Pro 7.

Comment 52

[Wan-Teh Chang]

Comment on attachment 59951 [details] [diff] [review]
patch for security

I reviewed this patch and made some suggested changes.
Please see my comments below.

Are these changes required to compile security/nss
under CW7 or are they compiler warning fixes?  If
they are compiler warning fixes, we will onl fix them
on the tip of NSS.

>Index: security/nss/lib/certhigh/ocsp.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v
>retrieving revision 1.1.86.1
>diff -u -2 -r1.1.86.1 ocsp.c
>--- ocsp.c	2001/08/07 18:54:57	1.1.86.1
>+++ ocsp.c	2001/11/30 23:49:48
>@@ -3709,5 +3709,5 @@
>        * look for the cert on an external token.
>        */
>-      cert = PK11_FindCertFromNickname(name, NULL);
>+      cert = PK11_FindCertFromNickname((char *) name, NULL);
>     }
>     if (cert == NULL)

This should be fixed by changing the function prototype of
PK11_FindCertFromNickname to take const char * as the first
argument.  I just filed bug 113323 for this change.

>Index: security/nss/lib/ckfw/object.c
>===================================================================
>RCS file: /cvsroot/mozilla/security/nss/lib/ckfw/object.c,v
>retrieving revision 1.4
>diff -u -2 -r1.4 object.c
>--- object.c	2000/05/16 01:54:45	1.4
>+++ object.c	2001/11/30 23:49:49
>@@ -33,5 +33,5 @@
> 
> #ifdef DEBUG
>-static const char CVS_ID[] = "@(#) $RCSfile: object.c,v $ $Revision: 1.4 $ $Date: 2000/05/16 01:54:45 $ $Name:  $";
>+static const char CVS_ID[] = "@(#) $RCSfile: object.c,v $ $Revision: 1.4 $ $Date: 2000/05/16 01:54:45 $ $Name: NSS_CLIENT_TAG $";
> #endif /* DEBUG */
> 
>@@ -627,5 +627,5 @@
>   }
> 
>-  mdItem = fwObject->mdObject->GetAttribute(fwObject->mdObject, fwObject,
>+  mdItem = (NSSItem *) fwObject->mdObject->GetAttribute(fwObject->mdObject, fwObject,
>     fwObject->mdSession, fwObject->fwSession, fwObject->mdToken, 
>     fwObject->fwToken, fwObject->mdInstance, fwObject->fwInstance,

This should be fixed by declaring the local variable mdItem as
const NSSItem *mdItem;

>Index: security/nss/lib/freebl/desblapi.c

All the changes to this fine are fine.	I probably would not
bother with the for-to-while changes; they are a matter of
style.

Comment 53

[Wan-Teh Chang]

Bob, could you merge the NSS patch (attachment 59951 [details] [diff] [review]), with my
suggested changes in comment #52, into the tip of NSS?  Thanks.

Comment 54

[Wan-Teh Chang]

Comment on attachment 59950 [details] [diff] [review]
patch for nspr

>Index: nsprpub/pr/src/io/prfile.c

The changes to this file are fine.

>Index: nsprpub/pr/src/md/mac/macdll.c

>Index: nsprpub/pr/src/md/mac/macio.c

>Index: nsprpub/pr/src/md/mac/macthr.c

>Index: nsprpub/pr/src/md/mac/mdcriticalregion.c

Please ask one of the Mac NSPR developers (sfraser, gordon,
beard, and sdagley) to review these Mac changes.

Comment 55

[Wan-Teh Chang]

Comment on attachment 59950 [details] [diff] [review]
patch for nspr

I found that Simon Fraser already noted in comment #43
that he reviewed the Mac part of this patch.  So I
am marking that this patch has been reviewed.  r=wtc.

Comment 56

[Conrad Carlen (not reading bugmail)]

> Are these changes required to compile security/nss under CW7 or are they
> compiler warning fixes?

They cause compiler errors. Changes would need to go onto NSS_CLIENT_TAG as well.

Comment 57

[Robert Relyea]

All of the NSS changes are already in the tip:
    object.c rev 1.5. by wtc for bug 94685
    desblapi.c rev 1.3 by wtc for bug 94685
    ocsp.c  rev 1.3 by relyea
NOTE: for integration into the CLIENT_BRANCH, please use rev 1.5 for object.c
The others files actually have identical patches to the proposed path.

bob

Comment 58

[Conrad Carlen (not reading bugmail)]

Thanks. Bob, can you check in the changes to the CLIENT_BRANCH?

Comment 59

[Wan-Teh Chang]

Attachment: patch for security

Patch for security per Bob Relyea's suggestion.
Conrad, when do you need this checked into
NSS_CLIENT_TAG?

Comment 60

[Conrad Carlen (not reading bugmail)]

By friday if possible. Thank you.

Comment 61

[Wan-Teh Chang]

Comment on attachment 60435 [details] [diff] [review]
patch for security

The patch for security has been checked into NSS_CLIENT_TAG.

Comment 62

[Mike Pinkerton (not reading bugmail)]

comments:

shouldn't the two occurances of

+                MenuRef menubar = static_cast<MenuRef>(clientData);

be reinterpret_cast instead? static_cast can't be used to cast to/from void*.
i'm surprised this compiles.

other than that, r=pink.

Comment 63

[Simon Fraser [no longer active]]

r/sr=sfraser

Comment 64

[Conrad Carlen (not reading bugmail)]

Thanks.
Pink, I changed the static_casts to reinterpret_casts.

Comment 65

[Conrad Carlen (not reading bugmail)]

Checked in amd .mcp files removed.

Comment 66

[J.J. Enser]

verified fixed.