Closed Bug 454120 Opened 12 years ago Closed 12 years ago
Problems Compiling SECURITY module for Win
4.59 KB, patch
|Details | Diff | Splinter Review|
4.34 KB, patch
|Details | Diff | Splinter Review|
1.28 KB, patch
|Details | Diff | Splinter Review|
1.76 KB, patch
|Details | Diff | Splinter Review|
Security module no longer compiles for WinMobile. The last time SECURITY was compiled for WinCE was WinCE version 4.2, a number of years ago. I have a patch with creates a new security/coreconf/WINCE.MK file, as well as modifies various files to facilitate compilation of the security modules. The patches here are all changes within the security module, while WinCE shunt and building tools changes are located in bug # 454119. NOTE: These are not the total sum of all changes needed to compile the security module -- this is only as far as I have gotten to date. I have fixed: (a) Proper compiler calling with appropriate pathname conversions (b) New WINCE.mk file, patterned after the Win954.0.mk file (c) Moved NSS version defines into their own header file, for RC compilation (d) Proper resource compiler calling with appropriate pathname conversions (e) Proper linker calling with appropriate pathname conversions First bug you will hit when trying to conpile security module for WinMobile is a link error because "main" is not defined for linking a DLL. WinMobile entry points should be DLLMain().
Comment on attachment 337368 [details] Collection of changes needed to make WinMobile compile the patch is binary, making it text.
Attachment #337368 - Attachment mime type: application/octet-stream → text/plain
wolfe, wtc and/or bs should review this.
Please attach a proper cvs diff. It should be a unified diff that bears enough information about the revision numbers of the files being patched that Bugzilla's patch diff tool can display the patch in context. Please separate NSS and PSM components into separate patches, since they are separate modules and have different reviewers.
Comment on attachment 337368 [details] Collection of changes needed to make WinMobile compile moa=kaie for change to security/manager/Makefile.in
This is the NSS portion of the above patch, converted to a cvs diff for review purposes. I haven't even built it, so I don't know if it compiles. I'm not trying to take ownership of this bug. Just showing what's desired for proper review. If this bug is predominately a set of requested changes to NSS, then it should be changed to product NSS, component build. Otherwise it will not show up on NSS reviewers' radar.
Comment on attachment 338671 [details] [diff] [review] above patch for NSS as a cvs unified diff Some initial review observations: 1. in the patch to coreconf/WINCE.mk we see: >+ DLLFLAGS += -OUT:"$@" >+echo break build here >+ # >+ # Add symbolic information for a profiler >+ # >+ ifdef MOZ_PROFILE break build here? Maybe this patch is not ready for prime time? 2. The version string copied into nssversion.h does not match the version string presently on the trunk. >--- security/nss/lib/nss/nss.h 11 Aug 2008 20:48:30 -0000 1.58 >+++ security/nss/lib/nss/nss.h 15 Sep 2008 16:47:15 -0000 >-#define NSS_VERSION "126.96.36.199" _NSS_ECC_STRING _NSS_CUSTOMIZED >-#define NSS_VMAJOR 3 >-#define NSS_VMINOR 12 >-#define NSS_VPATCH 1 >-#define NSS_BETA PR_FALSE >+#include "nssversion.h" >+++ security/nss/lib/nss/nssversion.h 15 Sep 2008 16:47:15 -0000 >+#define NSS_VERSION "188.8.131.52" _NSS_ECC_STRING _NSS_CUSTOMIZED >+#define NSS_VMAJOR 3 >+#define NSS_VMINOR 12 >+#define NSS_VPATCH 1 >+#define NSS_BETA PR_FALSE this makes me suspect that the changes recently done on the "mini branch" for NSS 184.108.40.206 were not also applied to the trunk. Kai, is that correct? If so, we've got some preliminary work to do on the trunk, ASAP.
Comment on attachment 338671 [details] [diff] [review] above patch for NSS as a cvs unified diff Wan-Teh, please review.
Comment on attachment 337368 [details] Collection of changes needed to make WinMobile compile Removed Review flag in favor of a CVS version of this diff file.
For attachment 338671 [details] [diff] [review], the file coreconf/WinCE.mk was created by taking the file coreconf/Win954.0.mk, modifying the contents and replacing the previous WinCE.mk In order to isolate my changes as much as possible, I replaced the line: include $(CORE_DEPTH)/coreconf/WIN32.mk with the current contents of coreconf/WIN32.MK The line within WinCE.mk which said "echo break build here" did not stop my compilation, and was a mistake which was left over from my trying to figure out how the security module build procedure actually works. I moved the version information from nss.h to its own file because the WinCE resource compiler is not very smart, and could not handle the various includes within the nss.h header file. When I had created the original patch, I had not realized how quickly the version information in nss.h is changed. Unfortunately, since the version information which I moved to nssversion.h changes frequently, that version information change is almost guaranteed to not apply cleanly. I am not sure what the best way is to get around this version information limitation. Should I create a patch that is JUST the version information moving to its own header file? That way, the version information migration could have a patch created, reviewed, and landed very, very quickly.
John, when I did a very cursory review of the patch, I found two issues, one of which was an issue with the patch, and one of which is an issue with the present state of the trunk, an issue which was revealed (not caused) by the patch. Don't worry about the version number mismatch. If and when the patch is committed, the committer can tweak the version number.
Same as attachment 337368 [details], except the "echo build breaks here" was removed.
Attachment #337368 - Attachment is obsolete: true
Same as attachment 338671 [details] [diff] [review], except the line "echo break build here" was removed from my new coreconf/WinCE.mk file.
John, thanks for producing the new patch. FYI, it isn't necessary to produce both CVS and Hg patches for NSS & NSPR because the CVS repository is the authoritative repository, and the Hg repository should just be a copy of the CVS repository contents as of the most recent CVS release tag. The process of copying the "snapshot" of the CVS repository to the Hg repository is automated, as I understand it.
Nelson, this is mostly me being paranoid, and figuring that it might take a while for these changes to land. Since we are trying to get more developers working with mozilla-central for WinMobile, I wanted to be able to point to a HG diff that these new developers can apply themselves, while the struggle continues to get these changes checked into the authoritative repository.
When Doug landed these changes today, he forgot to add the file nssversion.h This new file as derived from nss.h, and is a new file made by taking the contents of nss.h needed for compiling the resources for NSS. Hopefully, we can get this file landed in time to save the tinderbox from blowing up on Wed 25-Sep-08.
Comment on attachment 340289 [details] [diff] [review] HG Smaller patch with JUST NEW FILE NSSVERSION.H Remember, local hg patch queue is NOT mozilla-central main repository. My mistake as I was double-checking today's work tonight. Please ignore the totally wrong comment I previously made about tinderbox breaking.
Attachment #340289 - Attachment is obsolete: true
Assignee: wolfe → doug.turner
Attachment #340365 - Attachment is obsolete: true
Attachment #340956 - Flags: review?(nelson) → review-
Comment on attachment 340956 [details] [diff] [review] patch v.2 Please provide CVS diffs for NSS reviews. Don't use c++ style comments (//) in c code. I suggest you resist the urge to combine separate independent patches into one megapatch. The nssversion.h patches, for example, appear to be independent of the rest of the patches here. In the patch to secport.h, we see: >+// is there a better place for this >+#define _WIN32_WCE Yes, there must be. It CANNOT go in that file. Probably belongs in the wince file in coreconf. Please explain this comment: // This is because we redefine ERROR to anything via windows.h/shunt redefine ERROR to anything? Do WinCE developers have no choice but to use MSYS? I never used MSYS when I worked on NSS for WinCE. I'll do a more thorough review when I get the cvs diffs.
this patch moves the nss version information out of nss.h and into nssversion.h. this patch is required because the windows mobile rc.exe is dumb and doesn't understand some of the things that are in nss.h. nssversion.h will be included in the next attachment.
i think the coreconf stuff needs to either define _WIN32_WCE, or WINCE, or both. Right now we are a bit back and forth on our usage in NSS. Wolfe can you look at this? the other two parts of the original patch (to dbm and PSM) will be either resolved in other bugs. Hopefully we will not need them at all. Building without msys isn't supported now. Furthermore building NSS independent of the mozilla windows ce shunt (http://mxr.mozilla.org/mozilla-central/source/build/wince/shunt/) is not supported. lastly, ERROR is defined by WINCE SHUNT. It is also used as a macro in pkix. To avoid this, we need to redefine ERROR back to just ERROR. Sounds wierd, don't it.
It may be that building the browser requires MSYS, but today, NSS can be built with MSYS or MKS or even cygwin (I think), and I'd rather not impose a limitation on the shell packages with which NSS can be built just because mozilla browsers have settled on one. The technique used by NSS for such things is to let environment variables or values obtained from the uname command control them. There's already code that detects MinGW and sets MSYS for that environment. Also, the browser makefiles are free to define environment variables when building NSS as part of the browser. Please use one of those techniques rather than forcing all who build NSS for WinCE to adopt MSYS.
Comment on attachment 341008 [details] [diff] [review] nssversion patch Doug, Aside from the small problem that the version information that it would put into the new nssversion.h is not up to date, (the version has changed on the trunk), I agree in principle with this patch. But I have some questions. This patch changes 4 .rc files, corresponding to 4 of NSS's shared libs. But NSS now has 8 or 9 shared libs (one is optional) and 9 .rc files, listed below. I wonder why your patch doesn't touch all of them. lib/ckfw/builtins/nssckbi.rc lib/ckfw/capi/nsscapi.rc lib/freebl/freebl.rc lib/nss/nss.rc lib/smime/smime.rc lib/softoken/softokn.rc lib/softoken/legacydb/nssdbm.rc lib/ssl/ssl.rc lib/util/nssutil.rc
http://mxr.mozilla.org/mozilla-central/search?string=%23include+%22nss.h%22&find=\.rc&findi=&filter=&hitlimit=&tree=mozilla-central Only .rc files that #include nss.h were changed.
I updated the previous nssversion patch by making it apply cleanly to the trunk, and preserving the current trunk version numbers. Since this is primarily someone else's patch, I give it r+. Doug, please verify that I've accurately reproduced the patch. Julien, please review.
Comment on attachment 341041 [details] [diff] [review] nssversion patch brought forward to tip In keeping with the 8.3 naming convention that our public header files have faithfully followed, perhaps nssversion.h should be renamed nssver.h. Adding a new header just for the definition of the NSS version macros is fine if there is no other way to support WinCE's rc.exe. But the Win32 rc.exe has a predefined macro RC_INVOKED to solve exactly this problem: http://msdn.microsoft.com/en-us/library/aa381032(VS.85).aspx Does WinCE's rc.exe not define RC_INVOKED? An MXR search showed that the wince shunt also tests RC_INVOKED: http://mxr.mozilla.org/mozilla-central/search?string=RC_INVOKED So we should try the RC_INVOKED solution.
Wan-Teh, I don't think our public headers follow the 8.3 convention anymore. There are at least 2 public header files that don't : cmsreclist.h and utilrename.h . I am not aware of any platform where there is an 8.3 limit for header files.
Comment on attachment 341041 [details] [diff] [review] nssversion patch brought forward to tip This patch seems correct, though I'm not sure if it's required (see Wan-Teh's comments).
Attachment #341041 - Flags: review?(julien.pierre.boogz) → review+
Comment on attachment 341010 [details] [diff] [review] coreconf changes Having more thoroughly reviewed this patch, my overall impression is that most of this patch is fine, but some parts of it are not. These review comments are an expansion on my previous comment 20. The changes to PREFIXes, SUFFIXes, IMPORT_LIBRARY, SHARED_LIBRARY, and TARGET_OSES are all good. It appears that the Fennec project has made some project-specific choices for itself, such as - using MSYS and - using these curious alternative arm-wince-*.exe tools This patch would impose these choices on all who would build NSS for WinCE. It appears to me that this patch - eliminates the ability to build with any shell except MSYS - eliminates the ability use use WinCE with any CPU other than ARM, and - eliminates the ability to use Microsoft's free tools for building for WinCE, giving the user only the choice between gcc and arm-wince-gcc. The choices appear to be gcc or gcc. :( These choices may be entirely appropriate for the Fennec project, but IMO should not be imposed on all who would build NSS for WinCE. I won't want to see the fennec project's way of building NSS for WinCE become the ONLY way of building NSS for WinCE. IMO, Fennec should regard itself as a "downstream" project with respect to NSS, and in pushing changes "upstream" should do so in a way that doesn't reduce the choices for all other (potential) downstream projects. Please use another (new) make variable to enable the use of these new arm-wince-*.exe tools. The default should continue to be to use Microsoft's tools, with the use of GCC and the use of these arm-wince-* tools being alternatives enabled through make (environment) variables.
Attachment #341010 - Flags: review?(nelson) → review-
Comment on attachment 341041 [details] [diff] [review] nssversion patch brought forward to tip wtc's suggestion about RC_INVOKED works. patch coming up.
Attachment #341041 - Flags: review+ → review-
Attachment #341010 - Attachment is obsolete: true
Attachment #341041 - Attachment is obsolete: true
Attachment #341013 - Attachment is obsolete: true
this patch, as suggested by wan-teh, works fine using the windows mobile resource compiler. It simply surrounds the prototypes with an #ifndef RC_INVOKED block.
Attachment #344027 - Flags: review?(nelson)
Nelson, how is this? I still need to figure out a way to pass the correct AR from the security/manager/Makefile.in. (Ted, any ideas?)
figured out a way to pass in the right AR
Nelson's review is sufficient for me on the security/manager/Makefile.in bits.
Attachment #344175 - Flags: superreview?(nelson) → superreview-
Comment on attachment 344175 [details] [diff] [review] nss_build_changes v.2 1. Doesn't this define a symbol named LL ? Is that really the intended result? >+OS_DLLFLAGS += -DLL 2. this file is outside of NSS and has different review rules than NSS does. Please ask a PSM developer or BDS to review the change to this file. >diff --git a/security/manager/Makefile.in b/security/manager/Makefile.in >--- a/security/manager/Makefile.in >+++ b/security/manager/Makefile.in 3. Does WinCE include CAPI? Does it include the UI for managing Windows' cert store? If so, I'd think this would be desirable. >+ifneq ($(OS_ARCH),WINCE) > ifdef MOZILLA_CLIENT > NSS_BUILD_CAPI = 1 >+endif > endif 4. The patch makes the following change in several source files: >+// This is because we redefine ERROR to anything via windows.h/shunt >+#ifdef WINCE >+#undef ERROR >+#define ERROR ERROR >+#endif multiple comments about that: a) it uses //, a C++ comment in c code. Some (most) of the c compilers that build NSS will barf on it. b) I still don't know what "redefine ERROR to anything" means. #define ERROR anything ? At a minimum, a better comment is needed. c) I really hope there is a better solution to this problem, one that doesn't require peppering NSS with that #define. I'd try to offer a better solution, but I still don't entirely understand the problem. 5. This seems to say "if wince or not wince". To be or not to be? >diff --git a/security/nss/lib/ssl/win32err.c b/security/nss/lib/ssl/win32err.c >--- a/security/nss/lib/ssl/win32err.c >+++ b/security/nss/lib/ssl/win32err.c >@@ -44,7 +44,7 @@ > * ***** END LICENSE BLOCK ***** */ > /* $Id: win32err.c,v 1.4 2004/04/27 23:04:39 gerv%gerv.net Exp $ */ > >-#if !defined(_WIN32_WCE) >+#if !defined(_WIN32_WCE) || defined(WINCE)
(In reply to comment #39) > 4. The patch makes the following change in several source files: > > >+// This is because we redefine ERROR to anything via windows.h/shunt > >+#ifdef WINCE > >+#undef ERROR > >+#define ERROR ERROR > >+#endif Doug, we really need to keep the shunt from causing us to add clutter to so many files. This is just sloppy. Use a different shunt for these files, one that doesn't pull in windows.h Do these files need the shunt at all? or is the "shotgun" approach just adding the shunt unnecessarily?
@mfinkle is it a work around until we fix 456788. @nelson I will fix up the patch.
1) Yes. OS_DLLFLAGS += -DLL is required because we need to pass "-DLL" to any link that is intented to be a dll. This was also in the WINCE3.0.mk coreconf file. 2) Ted reviewed it (said it was okay, if you were okay with it). I am cc'ing Kaie as well. 3) I have enabled capi. thanks for spotting that. 4) Yes, as I mentioned above, it is a work around until 456788 is fixed. But I think mfinkle is right. we should address this problem now.
Comment on attachment 344027 [details] [diff] [review] Use of RC_INVOKED in nss.h looks like this will be OK.
Attachment #344027 - Flags: review?(nelson) → review+
nelson/ted, how do we get this checked in?
Please note: henceforth, I'm only going to review cvs diffs. I can't apply these git diffs to my cvs tree without a bunch of work that I shouldn't need to do.
@nelson fwiw, given a patch that has: b/security/nss/lib/nss/nss.h you could cd into the directory where nss.h is, and run patch -p5 < diff.txt
this is a comprehensive patch that allows us to build on windows mobile. GetProcAddress is now explicitly GetProcAddressA
Comment on attachment 344175 [details] [diff] [review] nss_build_changes v.2 Hopefully you weren't blocked on me here, but I can't review NSS changes anyway.
Comment on attachment 346493 [details] [diff] [review] patch v.3 ignore the change to GetProcAddressA.
This bug got to the head of my patch review queue yesterday, and POOF, the patch review request disappeared. My queue is very short right now, so ...
Comment on attachment 346934 [details] [diff] [review] patch v.3 This review applies to all parts of this patch except one. I did not review the diffs for security/manager/Makefile.in My review applies to the parts that are in NSS. r+, with one requested change and a comment. 1. In sslmutex.c and sslsnce.c, you removed "&& !defined(_WIN32_WCE)" from a #if. Evidently, that code, which formerly did not build for wince, now does. But in win32err.c, instead of removing that same #if, you changed it as: >-#if !defined(_WIN32_WCE) >+#if !defined(_WIN32_WCE) || defined(WINCE) That still reads to me like "if (A || !A)". Am I right that it means that? I think you probably just want to eliminate that #if and its matching #endif. 2. In comment 42 you wrote: > 3) I have enabled capi. thanks for spotting that. but this patch still disables the CAPI stuff. Well, if you want to build CAPI or not, that's your business. I just want to be sure that the part of this patch change changes security/nss/lib/ckfw/Makefile is not accidental.
Attachment #346934 - Flags: review?(nelson) → review+
win32err.c: We can safely remove the ifdef completely. There is NO need to ifdef for the wince platform. regarding the CAPI stuff -- there were some link errors: cobject.obj : error LNK2019: unresolved external symbol RpcStringFree referenced in function ckcapi_getContai cobject.obj : error LNK2019: unresolved external symbol UuidToString referenced in function ckcapi_getContain cobject.obj : error LNK2019: unresolved external symbol UuidCreate referenced in function ckcapi_getContainer I avoided including it as I am not sure there is even a need yet. It is easy enough to reinclude at some later point. Thanks for the reviews, Nelson!
same as v.3, but i have removed the #ifdefs from win32err.c relating to wince.
Attachment #346934 - Attachment is obsolete: true
Comment on attachment 347451 [details] [diff] [review] patch v.4 r=nelson for all parts except the patch to security/manager/Makefile.in which I did not review because it's outside of NSS. I have checked this in (except for security/manager/Makefile.in) I will shortly attach the CVS diff for the patch I committed. Bug 454120: Problems Compiling SECURITY module for WinMobile Patch by Doug Turner <email@example.com>, r=nelson coreconf/WINCE.mk; new revision: 1.4; previous revision: 1.3 coreconf/config.mk; new revision: 1.25; previous revision: 1.24 nss/lib/ckfw/Makefile; new revision: 1.15; previous revision: 1.14 nss/lib/nss/nss.h; new revision: 1.63; previous revision: 1.62 nss/lib/ssl/sslmutex.c; new revision: 1.21; previous revision: 1.20 nss/lib/ssl/sslsnce.c; new revision: 1.47; previous revision: 1.46 nss/lib/ssl/win32err.c; new revision: 1.5; previous revision: 1.4
Attachment #347451 - Flags: review?(nelson) → review+
WINCE.mk now has "OS_DLLFLAGS += -DLL", so we can remove that from WINCE3.0.mk, which includes WINCE.mk.
Attachment #349344 - Flags: review?(nelson)
Wan-Teh, It's not clear to me whether Dougt does or does not want WinCE builds to include the bridge-to-CAPI pkcs11 module. Also, what all versions of WinCE exist now? Should the +DLL line be in a new WINCE4.0.mk? or a WINCE5.0.mk? I can't answer these questions because I don't work on WinCE any more. This is a case where we need someone who is more up to date on WinCE than I am, and who understands the coreconf files structure to advise on where best to put that +DLL line.
Comment on attachment 349344 [details] [diff] [review] Minor tweaks Doug, could you review and test this patch? Thanks. WINCE3.0.mk: remove a line that's now redundant (was just added to WINCE.mk, which WINCE3.0 includes). lib/ckfw/Makefile: prevent the building of the 'capi' directory at the right place.
Attachment #349344 - Flags: review?(nelson) → review?(doug.turner)
As for versions of Windows CE / Windows Mobile, there is a lot of potential confusion. Right now, all WinCE efforts are actually to get the code base running within Windows Mobile 6 Professional devices (touch screen capable Windows Mobile 6 handsets). To further confuse things, WinMobile 6 is based upon WinCE 5.x - different WinCE minor versions apply to WinMobile 6.0 and WinMobile 6.1. Finally, I do not believe anyone has an interest in making Windows Mobile 5 (or earlier) work with the code base. Likewise, I believe that no one would want to make the code base work with a Windows CE version earlier than 5 (i.e., 4.2, 4.1, 4.0, 3.x, etc.) This means, for accuracy, that we should probably rename the WinCE3.0.mk to be WinCE5.0.mk. At some later date, if there is enough interest in making a distinction between Windows Mobile builds and Windows CE builds, then a lot of work will need to be done with any WINCE and _WIN32_WCE defines. For right now, all our efforts are focused on getting a WinMobile 6 build that works at all.
Comment on attachment 349344 [details] [diff] [review] Minor tweaks Nelson's comment 59 and John's comment 61 on WINCE5.0.mk made me realize that you are now using just WINCE.mk for all versions of WINCE, without using the version-specific WINCEx.y.mk files. (We do this for the platforms listed in TARGET_OSES.) So I will attach a new patch that cvs removes WINCE3.0.mk.
Remove parentheses that are no longer necessary after "&& !defined(_WIN32_WCE)" was removed.
Attachment #349445 - Flags: review?(nelson)
Comment on attachment 349443 [details] [diff] [review] Minor tweaks for makefiles (checked in) Doug, John, you may want to see if there's anything else you can salvage from WINCE3.0.mk. (Probably not, because you aren't using it.)
Attachment #349445 - Flags: review?(nelson) → review+
Comment on attachment 349445 [details] [diff] [review] Minor tweaks for lib/ssl (checked in) Checked in on the NSS trunk (NSS 3.12.3). Checking in sslmutex.c; /cvsroot/mozilla/security/nss/lib/ssl/sslmutex.c,v <-- sslmutex.c new revision: 1.22; previous revision: 1.21 done Checking in sslsnce.c; /cvsroot/mozilla/security/nss/lib/ssl/sslsnce.c,v <-- sslsnce.c new revision: 1.48; previous revision: 1.47 done
Attachment #349445 - Attachment description: Minor tweaks for lib/ssl → Minor tweaks for lib/ssl (checked in)
Doug, there is a patch attached to this bug, awaiting your review, for the issue about which you just filed bug 466215
Comment on attachment 347451 [details] [diff] [review] patch v.4 + CC="arm-wince-gcc.exe" \ + CCC="arm-wince-gcc.exe" \ Doesn't our build system set CC/CXX properly and you could just persist those values? Gonna make life harder for crowder if you hardcode values here. r=me on the security/manager bits.
Attachment #347451 - Flags: review+
Ted: configure.in at the top level doesn't set them right, but it should, I'll roll this part back when my stuff is done (and already have locally).
Comment on attachment 344027 [details] [diff] [review] Use of RC_INVOKED in nss.h This patch was superseded, and was never committed.
Attachment #344027 - Attachment is obsolete: true
Comment on attachment 347451 [details] [diff] [review] patch v.4 This is not the patch that was committed. The patch that was committed is the next one below this one.
Attachment #347451 - Attachment is obsolete: true
Comment on attachment 349443 [details] [diff] [review] Minor tweaks for makefiles (checked in) this patch, when applied to the windows mobile build, does not cause any problems. r=dougt
Attachment #349443 - Flags: review?(doug.turner) → review+
Comment on attachment 349443 [details] [diff] [review] Minor tweaks for makefiles (checked in) Doug, all the patches in this bug have been checked in. I think you can mark the bug fixed now. I checked in this patch on the NSS trunk (NSS 3.12.3). Removing coreconf/WINCE3.0.mk; /cvsroot/mozilla/security/coreconf/WINCE3.0.mk,v <-- WINCE3.0.mk new revision: delete; previous revision: 1.5 done Checking in nss/lib/ckfw/Makefile; /cvsroot/mozilla/security/nss/lib/ckfw/Makefile,v <-- Makefile new revision: 1.16; previous revision: 1.15 done
Attachment #349443 - Attachment description: Minor tweaks for makefiles → Minor tweaks for makefiles (checked in)
Comment on attachment 351511 [details] [diff] [review] patch v.5 -- mozilla/security makefile change Is this any different from the previous patch that I already gave r+? Also, note that only security/manager/Makefile.in is part of the mozilla build system, the rest is still NSS.
Attachment #351511 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 351511 [details] [diff] [review] patch v.5 -- mozilla/security makefile change this is exactly the same as the previous patch that you already reviewed. I teased it out of the previous patch so that we could point to what we are going to check in. but i goof'ed. ignore that change to security/nss/lib/ckfw/Makefile thanks for the r+
Comment on attachment 351511 [details] [diff] [review] patch v.5 -- mozilla/security makefile change double goof. i promise not to attach patches while drinking. The only thing that ted reviewed that matters for the check in is the change to : security/manager/Makefile.in
patch 351511 has been checked in: 555e338a03ca everything has been checked in now. Marking fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: General → Build
Product: Fennec → NSS
QA Contact: general → build
Version: Trunk → unspecified
verified with alpha 3...we can build;)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.