Re: 64bit NSS build on windows 7 x64
On 16.09.2010 15:28, David Stutzman wrote: > I've installed the latest mozilla-build, VS2008 Express SP1, the latest > windows SDK (7.1) and I'm just not getting too far in this process. > Linux is so much easier! > > I start up the shell with the start-msvc8-x64.bat script, which doesn't > seem to do/be anything different from start-msvc8.bat. For Visual Studio 2008, you should use start-msvc9-x64.bat. > but there's no mozconfig file that I can find to alter the host and target. Right, if you just want to compile NSS (and NSPR), then that's not needed. Simply add USE_64=1 to the nss_build_all make command (which you already did, from what I gather from the NSPR configure command). Out of curiosity, I just gave it a try with VC 2005, and the build went pretty smooth... a few more warnings than usual in the output (compared to a 32-bit build), but the binaries at least seem to load :-) Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: 64bit NSS build on windows 7 x64
On 09/16/2010 11:38 AM, Benjamin Smedberg wrote: On 9/16/10 6:28 AM, David Stutzman wrote: I start up the shell with the start-msvc8-x64.bat script, which doesn't seem to do/be anything different from start-msvc8.bat. The 64-bit compiler seems to be installed from the SDK. If possible I'd like to target from XP 64 on up as far as compatibility, but I'd settle for having it run on my workstation only which is Win7 64. Why do you want to build a 64-bit version? Perhaps he wants to use the library in something other than Mozilla? Perhaps he wants to allocate more than a few hundred MB in one chunk? Perhaps he wants to get valid stack traces in his crashdumps? (no FPO) The 32-bit version will run even on 64-bit versions of windows, and is much more common in general. The typical Windows PC sold though retail channels has been 64 bits for many years now. On the other hand, XP 64 is definitely weird. I recommend starting out building a 32-bit version and condider the 64-bit version an advanced topic that is much more likely to break. Good advice, but that situation really should change at some point. I've installed the latest mozilla-build, VS2008 Express SP1, the latest windows SDK (7.1) and I'm just not getting too far in this process. Linux is so much easier! That's for sure. After programming Windows for so long, it's really weird to be able to just #include headers and -l packaged libraries and have it actually work. I've hacked the path so when I type cl I get the right one: You mentioned that you installed MSVC and the SDK. There's a good deal of overlap between them. For example, they both supply standard headers, compilers, and system link libraries. There's some script to get the compiler to use the paths from the SDK in the IDE. Last I checked (MSVS2k5), this only affected the IDE and didn't work for command-line builds. So there's the plain IDE, the IDE after SDK integration, vcvars.bat for the compiler, and the scripts to launch the SDK build environments. In my experience, all of them end up yielding subtly different build environments. I've always felt the need to just define my own build environment variables by hand. That way I can set it the same in both the IDE and on the command line. That's coming from someone who expects to support this process as a full-time job though, so my advice is a minority view for most open source projects (and not MS's precise recommendation either). This shouldn't be necessary if you're using start-msvc8-x64... One thing that bites me sometimes is there are spaces or parentheses in the path or other environment variables. It turns out that parentheses are meta-characters for the NT command prompt interpreter (the scripting language so bad it doesn't even have a name). Of course we all know the fun we can have with spaces in the path. Of course, some joker decided it would be a good idea to name a critical directory "Program Files (x86)", breaking innumerable scripts in the process. checking whether the C compiler (cl ) works... no configure: error: installation or configuration problem: C compiler cannot creat e executables. make: *** [../../nsprpub/WINNT6.1_64_OPT.OBJ/config.status] Error 1 This might be an intermittent problem we've been seeing which is unrelated to the compiler (failure to remove a file which is in use), but you really need to check config.log to see what the actual failure was. Can you post the environment that's seen at the point 'cl' is invoked? (Check over it and X-out any sensitive info first). You might be able to do this by creating a "cl.cmd" file in the current directory with just the "set" command in it. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: 64bit NSS build on windows 7 x64
On 9/16/10 6:28 AM, David Stutzman wrote: I start up the shell with the start-msvc8-x64.bat script, which doesn't seem to do/be anything different from start-msvc8.bat. The 64-bit compiler seems to be installed from the SDK. If possible I'd like to target from XP 64 on up as far as compatibility, but I'd settle for having it run on my workstation only which is Win7 64. Why do you want to build a 64-bit version? The 32-bit version will run even on 64-bit versions of windows, and is much more common in general. I recommend starting out building a 32-bit version and condider the 64-bit version an advanced topic that is much more likely to break. I've hacked the path so when I type cl I get the right one: This shouldn't be necessary if you're using start-msvc8-x64... checking whether the C compiler (cl ) works... no configure: error: installation or configuration problem: C compiler cannot creat e executables. make: *** [../../nsprpub/WINNT6.1_64_OPT.OBJ/config.status] Error 1 This might be an intermittent problem we've been seeing which is unrelated to the compiler (failure to remove a file which is in use), but you really need to check config.log to see what the actual failure was. --BDS -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: 64bit NSS build on windows 7 x64
On 16. 9. 2010 15:28, David Stutzman wrote: configure: error: installation or configuration problem: C compiler cannot creat e executables. Just guessing here... could this be a problem with UAC? (User Account Control) M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
64bit NSS build on windows 7 x64
I give up...can you guys point me to some directions for this? I've installed the latest mozilla-build, VS2008 Express SP1, the latest windows SDK (7.1) and I'm just not getting too far in this process. Linux is so much easier! I start up the shell with the start-msvc8-x64.bat script, which doesn't seem to do/be anything different from start-msvc8.bat. The 64-bit compiler seems to be installed from the SDK. If possible I'd like to target from XP 64 on up as far as compatibility, but I'd settle for having it run on my workstation only which is Win7 64. I read this: http://wiki.mozilla-x86-64.com/How_To_Build_Windows_x64_Build, but it seems it's more browser aligned than just NSS. The part "Note that --target and --host have to set x86_64-pc-mingw32 due to no uname.exe for x64. " seems important, but there's no mozconfig file that I can find to alter the host and target. I've hacked the path so when I type cl I get the right one: $ cl Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. But I don't get too far in make nss_build_all before it blows up (I'm guessing because host/target/build system type are all 32bit?): nsinstall -D ../../nsprpub/WINNT6.1_64_OPT.OBJ cd ../../nsprpub/WINNT6.1_64_OPT.OBJ ; \ sh ../configure \ --disable-debug --enable-optimize --enable-64bit \ --with-dist-prefix='$(topsrcdir)/../dist/WINNT6.1_64_OPT.OBJ' \ --with-dist-includedir='$(topsrcdir)/../dist/WINNT6.1_64_OPT.OBJ/include ' loading cache ./config.cache checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking build system type... i686-pc-mingw32 checking for cl... cl ../configure: line 803: CC: command not found configure: warning: test failed. Using normal feature tests checking for whoami... /c/Windows/System32/whoami checking for gcc... (cached) cl checking whether the C compiler (cl ) works... no configure: error: installation or configuration problem: C compiler cannot creat e executables. make: *** [../../nsprpub/WINNT6.1_64_OPT.OBJ/config.status] Error 1 Ugh... Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Can a ssl3.ca_list be configured on a model file descriptor?
Hi, I have configured a model file descriptor using SSL_SetTrustAnchors(PRFileDesc *fd, CERTCertList *list) The ssl3.ca_list information set in the model is not copied into the new file descriptor when calling PRFileDesc *SSL_ImportFD(PRFileDesc *model, PRFileDesc *fd); Could it be that the SSL_SetTrustAnchors() should be called every time on the PRFileDesc returned by SSL_ImportFD()? Regards, Wolter Eldering -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
