nsinstall -D ../../nsprpub/WINNT5.2_64_DBG.OBJ cd ../../nsprpub/WINNT5.2_64_DBG.OBJ ; \ sh ../configure \ --enable-64bit \ --with-dist-prefix='C:/NSS/tip/mozilla/security/nss/../../dist/WINNT5.2_64_DBG.O BJ' \ --with-dist-includedir='C:/NSS/tip/mozilla/security/nss/../../dist/WINNT5.2_64_D BG.OBJ/include' loading cache ./config.cache checking host system type... mkdir: directory "/tmp/cg2740-17029": The system ca nnot find the path specified. mkdir: directory "/tmp/cg-2740": The system cannot find the path specified. config.guess: cannot create a temporary directory in /tmp configure: error: can not guess host type; you must specify one gmake: *** [../../nsprpub/WINNT5.2_64_DBG.OBJ/config.status] Error 1 If I create C:\TMP, I also get this info page : This script, last modified 2005-10-13, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess and http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub If the version you run (../build/autoconf/config.guess) is already up to date, p lease send the following data and any information you think might be pertinent to <firstname.lastname@example.org> in order to provide the needed information to handle your system. config.guess timestamp = 2005-10-13 uname -m = x86_64 uname -r = 5 uname -s = Windows_NT uname -v = 02 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = x86_64 UNAME_RELEASE = 5 UNAME_SYSTEM = Windows_NT UNAME_VERSION = 02
Note that the 64-bit build on the same machine succeeds with cygwin . The 32-bit build succeeds with both MKS and cygwin .
Julien: it seems that you need to modify NSPR's config.guess, imitating the code here: http://lxr.mozilla.org/nspr/source/nsprpub/build/autoconf/config.guess#791 to recognize "x86_64:Windows_NT:*".
Wan-Teh, I don't think the NSPR configure script should depend on the value of uname -m being x86_64 . Removing that dependency would be a better fix. No versions of uname.exe for Windows are returning this value anyway. IMO, if NSPR detects an x86 processor, and the --enable-64-bit option is passed in, then that should be sufficient to determine that the target is x86_64 / AMD64 . This would be consistent with other multi-bitness architectures which allow producing a 64-bit build only by setting the --enable-64-bit option, without having two different values for uname -m .
I didn't realize the NSPR support for Windows AMD64 wasn't final yet. Since bug 225859 is still open, I'm marking this as a dupe of that bug. I will convey my comments about configure in it. *** This bug has been marked as a duplicate of 225859 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.