This is a place holder for getting mozilla 6.2.2 building on IPF (hp-ux 11.20 - ia64)
Status: NEW → ASSIGNED
QA Contact: granrose → paulmac
This patch contains most of the build changes required to get MOZILLA_6_2_2_BRANCH working on ipf (hpux 11.20 on ia64) using aCC x.05.32.09. does not include all of the nspr files
Comment on attachment 78188 [details] [diff] [review] 1st set of patches to get mozilla 622 working on ipf patches checked into MOZILLA_6_2_2_BRANCH
did you really check in bare printfs? ah, yes you did. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/unix_rand.c&rev=NETSCAPE_6_2_2_BRANCH&mark=#1 does that make sense?
Adding the rules.mk change to only export the required symbols from Components. This gives us a 10% reduction in binary size and should improve loading performance. Also change from using _pr_CopyLowBits to CopyLowBits. _pr is in nspr and "shouldn't" be exported whereas we should be using the call inside of sec utility.
Summary: get mozilla 622 branch building on ipf → get mozilla branch building on ipf
As of 8/16, this cumulative patch is sufficient to make the OEM branch build on IPF.
Comment on attachment 95934 [details] [diff] [review] Latest complete patch set Need to keep some of these patches separate. Ignore this.
Attachment #95934 - Attachment is obsolete: true
Changes checked into OEM branch.
The other parts of the original patch have been picked up by other bugs. This one patch is the major one needed for this bug now.
adding cls&jband because they can r=/sr= the changes to xpcom/reflect/xptcall/src/unix/Makefile.in I think I can just get away with cls's, but added jband just to keep him in the loop. cls, what do you think?
Comment on attachment 100247 [details] [diff] [review] latest diff r=cls
Attachment #100247 - Flags: review+
fix checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.