Re: Using MSVC as a cross compiler
Wan-Teh Chang wrote: NSS uses LD on Unix (including Linux and Mac OS X), and LINK on Windows, to refer to the linker. It also uses $LINK_DLL on Windows and $MKSHLIB everywhere else. How inconsistent :-( -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Neil wrote: Wan-Teh Chang wrote: You'll see that the Mozilla developers override these make variables used by the NSS coreconf build system when cross-compiling NSS: 199 ifdef CROSS_COMPILE 200 DEFAULT_GMAKE_FLAGS += \ 201 NSINSTALL=$(NSINSTALL) \ 202 NATIVE_CC=$(HOST_CC) \ 203 CC=$(CC) \ 204 CCC=$(CXX) \ 205 LINK=$(LD) \ 206 AS=$(AS) \ 207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \ 208 RANLIB=$(RANLIB) \ 209 RC=$(RC) $(RCFLAGS) \ 210 OS_ARCH=$(OS_ARCH) \ 211 CPU_ARCH=$(TARGET_CPU) \ 212 $(NULL) 213 SKIP_CHK=1 214 endif So, the fact that AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' doesn't work is a Mozilla bug rather than an NSS bug? Which component would I need to file it under? You can file a bug under the component Core:Build Config. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Wan-Teh Chang wrote: I can point you to the relevant Mozilla makefile: http://lxr.mozilla.org/security/source/security/manager/Makefile.in#199 You'll see that the Mozilla developers override these make variables used by the NSS coreconf build system when cross-compiling NSS: 199 ifdef CROSS_COMPILE 200 DEFAULT_GMAKE_FLAGS += \ 201 NSINSTALL=$(NSINSTALL) \ 202 NATIVE_CC=$(HOST_CC) \ 203 CC=$(CC) \ 204 CCC=$(CXX) \ 205 LINK=$(LD) \ 206 AS=$(AS) \ 207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \ 208 RANLIB=$(RANLIB) \ 209 RC=$(RC) $(RCFLAGS) \ 210 OS_ARCH=$(OS_ARCH) \ 211 CPU_ARCH=$(TARGET_CPU) \ 212 $(NULL) 213 SKIP_CHK=1 214 endif Neil then asked: So, the fact that AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' doesn't work is a Mozilla bug rather than an NSS bug? Yes. It is a bug in a source file that is not part of NSS, but is part of mozilla. Ergo, it is not an NSS bug. I believe that the code in security/manager is part of PSM. PSM stands for Personal Security Manager. That's the manager in security/manager. NSS code is (mostly) in security/nss. Also, NSS shares security/coreconf with JSS (and maybe other components I'm forgetting). Which component would I need to file it under? PSM bugs get filed in product core, component security:PSM But it is a Makefile, and so is also eligible to be filed as a build component bug (as Wan-Teh suggested). I don't know which of those components will get you a response sooner. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Wan-Teh Chang wrote: None of the NSS developers cross-compiles NSS. (The closest thing we do to cross-compilation is to build the Windows CE binaries on Windows 2000/XP.) So we're not familiar with how the Mozilla developers cross-compile NSS. I don't think many Mozilla developers cross-compile NSS either ;-) except perhaps Intel Mac - PPC. You'll see that the Mozilla developers override these make variables used by the NSS coreconf build system when cross-compiling NSS: 199 ifdef CROSS_COMPILE 200 DEFAULT_GMAKE_FLAGS += \ 201 NSINSTALL=$(NSINSTALL) \ 202 NATIVE_CC=$(HOST_CC) \ 203 CC=$(CC) \ 204 CCC=$(CXX) \ 205 LINK=$(LD) \ 206 AS=$(AS) \ 207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \ 208 RANLIB=$(RANLIB) \ 209 RC=$(RC) $(RCFLAGS) \ 210 OS_ARCH=$(OS_ARCH) \ 211 CPU_ARCH=$(TARGET_CPU) \ 212 $(NULL) 213 SKIP_CHK=1 214 endif Yes, and this is the cause of the third issue in my original post :-( I wonder why NSS uses LINK instead of LD? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Nelson B wrote: I suggest that you first try to get NSS to build for you in its stand-alone configuration, using only NSS's makefiles and not any of the other mozilla products' makefiles. Where would this be documented, with specific reference to cross compilation? -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Neil wrote: Myself using Interix and Mook using Wine have both tried to cross-compile Mozilla using MSVC as a cross compiler. Generally I would like to think that NSS has been the easiest part to cross compile, but here are the issues we ran into: 1. Because we're not using GCC or MSYS, rules.mk tries to run cygpath -w `pwd` which fails because we have no cygpath. 2. AR does not get set correctly because AR_FLAGS contains $@ 3. LINK fails to run because the environment contains LINK=link which it sees as a request to link link.obj 4. RC fails to run because some of the NSPR includes can't determine the target processor (_X86_ does not get defined) 5. Because he was using VC8 Mook also had some issues with manifests. I would be happy to write patches for these if you would advise me as to whether my ideas are useful. 1. I wrapped the code in a test for NATIVE_CC; Mook used CROSS_COMPILE but I think that relies on you exporting it from the shell. 2. AR='$(subst $@,$$@,$(AR) $(AR_FLAGS))' (Mook used a similar construct) 3. Mook prefixed LINK= $(LINK) to temporarily clear the variable; my suggestion is to rename $(LINK) to $(LD) in the makefile 4. Currently we work around this by preventing rc from including seccommon.h but I'd appreciate ideas for how to persuade NSS that i686 is _X86_ 5. I don't know about this, but I could ask Mook to chime in if you thought it would be useful. Neil, This is not a direct answer to any of the issues you raised, but is a suggestion on how best to go about addressing them. As you may know, NSS and NSPR can be built independently of the rest of the mozilla products (browsers, email clients, etc.). NSS and NSPR have their own build system (Makefiles). The mozilla products' build systems provide wrappers that invoke NSS+NSPR's build systems. When you try to build FireFox or ThunderBird, the makefiles for those products also try to make NSS. When people have trouble building NSS inside of one of the mozilla products, the problem may be in the NSS makefiles, or it may be in the wrappers. Sometimes people try to fix problems in one by making changes to the other. That has been the cause of no little grief in the past. If you're having problems building NSS for some particular platform, I suggest that you first try to get NSS to build for you in its stand- alone configuration, using only NSS's makefiles and not any of the other mozilla products' makefiles. When you have that working, then the next step (if you still need it) is to get NSS building as part of the mozilla product builds. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Neil wrote: Nelson B wrote: I suggest that you first try to get NSS to build for you in its stand-alone configuration, using only NSS's makefiles and not any of the other mozilla products' makefiles. Where would this be documented, with specific reference to cross compilation? In the usual places where NSS documentation is found. Here's a helpful google search. http://www.google.com/search?q=NSS+build+instructions+site:mozilla.orgnum=100hl=enlr=safe=offas_qdr=allfilter=0 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using MSVC as a cross compiler
Neil, None of the NSS developers cross-compiles NSS. (The closest thing we do to cross-compilation is to build the Windows CE binaries on Windows 2000/XP.) So we're not familiar with how the Mozilla developers cross-compile NSS. I can point you to the relevant Mozilla makefile: http://lxr.mozilla.org/security/source/security/manager/Makefile.in#199 You'll see that the Mozilla developers override these make variables used by the NSS coreconf build system when cross-compiling NSS: 199 ifdef CROSS_COMPILE 200 DEFAULT_GMAKE_FLAGS += \ 201 NSINSTALL=$(NSINSTALL) \ 202 NATIVE_CC=$(HOST_CC) \ 203 CC=$(CC) \ 204 CCC=$(CXX) \ 205 LINK=$(LD) \ 206 AS=$(AS) \ 207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \ 208 RANLIB=$(RANLIB) \ 209 RC=$(RC) $(RCFLAGS) \ 210 OS_ARCH=$(OS_ARCH) \ 211 CPU_ARCH=$(TARGET_CPU) \ 212 $(NULL) 213 SKIP_CHK=1 214 endif To build NSS stand-alone, cd mozilla/security/nss gmake nss_build_all The 'nss_build_all' makefile target also builds NSPR (mozilla/nsprpub). You can study mozilla/security/nss/Makefile to see how we do that. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
