I wanted to add to the points above that it does not make a difference if I use /DWIN32 or /D_WIN64 during compile
Are you using MSVS 2005? What is the 2003 SDK customized for AMD64?
When you are setting the libraries and includes, are you looking for the library and include paths for Brook+ includes and libraries?
As far as brook_d.exe goes, you shouldn't need to use that binary (I've already reported this to the Brook+ team by the way) since you are not trying to debug Brook+.
You should link with the 64-bit version of CAL if you compile for 64-bit under Brook+.
When you are compiling under 64-bit, have you set the "bitness" option from "Win32" to "x86_64"/"x64" (I forget which it is since I don't have a 64-bit machine available to check on at this moment). This is next to the place on the toolbar where you select "Release"/"Debug".
I thought that brook_d.exe add some debug feature to the output code. It seems that this is not the case.
This is the Micosoft server 2003 R2 platform SDk released on March 2006. It is supposed to build apps for x86, x86_64 under Windows XP 32, x64 and Windows 2003 server:
I have used it successfully to build apps on 32b XP, using Brook+. I am using both VS2005 & batch files. The batch files use command lines copied from Brook+ samples under vs2005
It has a whole binary branch for AMD64 architecure (cl.exe, link.exe, lib.exe). The directory path under the sdk is:
Microsoft Platform SDK for Windows Server 2003 R2\Bin\win64\x86\AMD64
The binaries (cl.exe, lib.exe, link.exe) that come with vs2005 express do not launch from vs2005 under xp64
The same applies for Lib & Include Directories:
Microsoft Platform SDK for Windows Server 2003 R2\Lib\AMD64
Microsoft Platform SDK for Windows Server 2003 R2\Include\crt , same...\sys
I used the above SDK paths successfully to port 32b linux apps to windows x64/AMD64. The only issue is with linking to brook+.
I believe for settings you use /D_WIN64 (or possibly /DWIN64), and /D_AMD64 for compiler, and for linker /MACHINE:AMD64.
I will have to make sure I am having a path for CAL 64 (I assume the installation automatically did that).
Maybe if you just tell me the official procedure for linking a Brook+ application to a 64b code compiled under XP x64 as "64b", I will just follow yours
I have confirmed that I have the CAL libs in my path, and explicitly added the two static libraries under the x64 lib directory. Nothing has changed.
The same complain when I use the /MD option: MSVCP80.dll
We've created a simple example that should build in a straightforward way.
Here's the Q/A from the soon-to-be-posted FAQ, can you please give that a shot?
Q: I have build/runtime errors on Windows, how to I track down the cause?
A1: Download hello_brook from the following location:
Drop the project directory into your Desktop, and select Win32 or x64
build targets, depending on our system. Assuming you have CAL and Brook
installed, this example should build in either combination of
If your own project does not build, compare the following properties between
your project and the example project:
Project->Properties->Configuration Properties->C/C++->Command Line
Project->Properties->Configuration Properties->Linker->Command Line
Please refer to the Visual Studio documentation on how to select the various
property settings that eventually result in these two command lines.
I will give it a try and let you know
I also had error message reporting that MSVCP80.dll is missing each time I tried to run my program in debug mode. In the end, I have realized that I have forgotten to set brook_d.lib, instead of brook.lib under "Additional Dependencies" in Debug configuration of the project.
I'm runnning VS2008 on winXP64. Whenever I try to compile the examples in the solutions, I get Error: Only Win32 target supported! thrown from typeinfo.h. My target it set for Win32 and I even tried adding _WIN32 to the preprocessor define list in the solution, but neither of these seem to mitigate the error. Do any of the headers do a #undef _WIN32 of something?
Nevermind, I found it. If you're having trouble compiling in VS2008, open brtvector.hpp and comment out the #undef _WIN32 on line 37.