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 sooooo 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
