cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

bayoumi
Journeyman III

brook+ on XP x64 / AMD64

Hi,
what is the "official" procedure to compile & link a brook+ applications such as hello_brook.br under XP x64 running on a Phenom AMD64?
The specific questions are:
1- should I be using the compiler/linker under 2003 SDK customized for AMD64? Please not that the ones originally under VC/bin do not launch from xp64.
2- Which libraries & includes for both /MT & /MD, the ones under the SDK & AMD64 directory or the ones under VC2005?
3- I was not able to run the brook_d.exe that comes with xp64 brook kit, only the brook.exe
4- Assuming I recompile the brook library using 64bit compile/link, will I be able to link to 32b cal layer?

5- I tried everything, but it seems it does not recognize the brook.lib at all. Things go through only if I use everything x64/AMD64 bin, lib & includes. I get one of the following errors:
a- using either /MDd or /MD, the .exe file generated, but at runtime it complains MSVCP80D.dll /MSVCP80.dll not there. In the release build case, the dll is there!
b- using /MTd or /MT, it complains during linking about unresolved externals such as kernel, ... I get the same result if I do not include the brook_d/brook.lib in the path!

6- I get the same results regardless I work from batch files or vc2005
7- Using the brook.lib under the xp32 SDK does not help

Thank you
Amr
0 Likes
9 Replies
bayoumi
Journeyman III

I wanted to add to the points above that it does not make a difference if I use /DWIN32 or /D_WIN64 during compile

Thanks
Amr
0 Likes

Hi Amr,

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".

Michael.
0 Likes
bayoumi
Journeyman III

Hi Michael
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:
http://www.microsoft.com/downl...19ca0d&displaylang=en

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

Thanks
Amr
0 Likes
bayoumi
Journeyman III

Hi Michael
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
Thanks
Amr
0 Likes


Hi,

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:

ftp://streamcomputing:streamcomputing@ftp-developer.amd.com/samples/

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
Win32/x64/Release/Debug.

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.

0 Likes
bayoumi
Journeyman III

Thanks
I will give it a try and let you know
Amr
0 Likes

bayoumi,
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.
0 Likes

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?

0 Likes

Nevermind, I found it. If you're having trouble compiling in VS2008, open brtvector.hpp and comment out the #undef _WIN32 on line 37.

0 Likes