cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

ryta1203
Journeyman III

Brook and Visual Studio

I am having a problem with Brook+ building/compiling in VS.

I have installed VS2008 and then installed the Firestream SDK (CAL and Brook+). Following the Programming Guide (that came with the SDK) for Brook+ I used the "four" step process to add the needed lines to the .br file properties.

Essentially here are my problems:

http://www.gpgpu.org/forums/viewtopic.php?t=5080


http://www.gpgpu.org/forums/viewtopic.php?t=5085


Unfortunately it doesn't seem that the gpgpu.org forum members have much experience in this matter and the documentation for the Firestream SDK is extremely limited. Also, it unfortunately appears that the SDK is only available for WinXP, so I am using VS and building with "Solutions" (not "make"). I don't understand not using VS if you have to use Windows, why command line it?

Isn't the point of having a WinXP release to minimize the difficulty for non-CS personnel to get the software up and running? Or is it just because Brook has a better DX backend than a GL backend? As it stands right now using Brook is pointless, IMO due to the difficulty of getting it to run (I can't even get the samples to build and execute properly), since CAL seems to run fine out of the box.

I'm sure it's not a "Brook" thing so much as a "Brook in VS" thing.

Anyone else having these problems?
0 Likes
38 Replies

Ryta,
I am sorry that you are having trouble with Brook+ building in VS2008. However, according to the BrookPlusProgrammingGuide.pdf in the doc directory, the System Requirements state that Visual Studio 2005 is the supported version. As we haven't tested with VS2008 yet, we cannot guarantee that it works. Visual Studio 2005 should work out of the box.
As for the command line, not everyone uses the solutions file, like myself, and prefer the command line even when using Windows. So both options are available to give people choice.
We currently have planned support for 32 and 64 bit Vista, Linux and Windows in the next release.

Give it a shot with VS2005 and let use know if there are any problems there.
0 Likes

Just a slight correction...

Our next release will have Win XP 32/64 support but not Win Vista 32/64 support.
0 Likes
MfA
Journeyman III

Replied to the first post on gpgpu.com with what I did to get the brook+ examples to build with VS2008.
0 Likes

Thanks MfA and Michael and Micah for all the help. I guess I will be downgrading to VS 2005 for now. It would be nice in the future to be able to use 2008 (and any other newer versions) with this new SDK.

Thanks again.
0 Likes

After installing MS VS 2005 and trying to run Brook sample "accumulate" I still get the same problem; HOWEVER, these are now "warnings" instead of "errors":


1>Linking...
1>brook_d.lib(brt.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(logger.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(calstream.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(calruntime.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(gpuiterator.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(gpustream.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(gpuruntime.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(gpukernel.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpuwritequery.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpuwritemask.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpuiter.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpuruntime.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpukernel.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>brook_d.lib(cpustream.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\\sdk\lib\\brook_d.lib' or at 'c:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\samples\bin\xp_x86_32\vc80.pdb'; linking object as if no debug info
1>Embedding manifest...


Any ideas as to what is wrong? What do I need to add/remove/etc..? Thanks.
0 Likes

ryta1203,
The issue here is that it is linking against the debug version of the library, however, the debug database, "vc80.pdb", isn't there for the requested object files. Since these are only warnings, there should be no problem with the running of the program and can be safely ignored.
0 Likes

Micah,

So is this a problem with Brook+ or a problem with something I didn't install/setup?
0 Likes

It just looks like we didn't include the vc80.pdb database in the Brook+ installation. However, since your main objective actually isn't debug the Brook+ runtime (that's our job 🙂 ) but rather debug your Brook+ code, then linking against the brook_d.lib shouldn't be necessary.

If you are doing Debug builds and repurposing one of the sample app project files, you should be able to just go into the additional linker input dependencies in the project properties and change the reference of brook_d.lib to brook.lib

Michael.
0 Likes

EDIT: I wasn't trying to repurpose it, just build it. Also, so far I am working on a .br file and this doesn't seem to be a problem, so far. Either way I will just ignore it. Thanks.

Ok,

So I have compiled my .br file, but now when I go to compile the .cpp file I get this error:

fatal error C1083: Cannot open include file: 'brook/brook.hpp': No such file or directory

Sorry for all the trouble, I'm sure a lot of this comes with my inexperience with VS/linkers.

EDIT: I have added the appropriate $(BROOKROOT)\sdk\include to the Projects and Solutions, VC++ Directories, Include Files section of VS2005. Should this have been included automatically by the installer?

EDIT: Although I can compile the .br file and then the .cpp file, the solution will not build:
ERROR: error LNK2019: unresolved external symbol "class brook::Runtime * __cdecl brook::createRuntime(bool)" (?createRuntime@brook@@YAPAVRuntime@1@_N@Z) referenced in function "private: __thiscall `anonymous namespace'::AtStartup::AtStartup(void)" (??0AtStartup@?A0xa34aacc9@@AAE@XZ)

I took out all the brook code but I still get this error.

I'm a bit confused as to why I am having so many problems with this. I have read the Guide and Spec pdfs for Brook+ and installed everything step by step per the Guide. Also, I have done no tweaking or changing to anything and am trying to run this right out of the box.
0 Likes

There are bound to be a few gotchas and that's what we are here for. 🙂 I apologizes for the difficulties you've been having. Hopefully I can help you get up and running quickly. 🙂

When you added $(BROOKROOT)\sdk\include to Project Properties->Configuration Properties->C/C++->Additional Include Directories, did that make the "cannot open include file: 'brook/brook.hpp'" error go away?

Also, make sure BROOKROOT has been set properly. It should be been done for you with the installer. Go to Start->Run and run "cmd". Type: "echo %BROOKROOT%" and make sure it is pointing to C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\

The include path is something you need to add to all of your projects manually. MSVS has no way of knowing you want that path in your include path vs. some other path. If it put it in automatically, you might end up getting conflicts between 2 different packages which have similarly named include files. Then, it would be which ever include path was first which wins. No desireable behaviour.

The only way for this to be automatically in your include paths would be if we installed Brook+ and CAL include files and library file directly into your MSVS directories which wouldn't be a very clean thing to do. We prefer to keep our files separate so it makes for easy updates, etc.

Also, as far as the linking is concerned (the LNK2019 error), do you have Project Properties->Configuration Properties->Linker->Input->Additional Dependencies set to "$(BROOKROOT)\sdk\lib\brook.lib"? You need to make sure the double-quotes are there. BROOKROOT, as it is setup by default, has spaces in its resolution. This will confuse MSVS and it will end up thinking there are 2 dependencies there (it seems to handle spaces in the resolution of BROOKROOT for the include path for some reason).

Give that a try and let me know how it goes.

Michael.
0 Likes

Originally posted by: michael.chu@amd.com

There are bound to be a few gotchas and that's what we are here for. 🙂 I apologizes for the difficulties you've been having. Hopefully I can help you get up and running quickly. 🙂

Thank you, I appreciate it!

When you added $(BROOKROOT)\sdk\include to Project Properties->Configuration Properties->C/C++->Additional Include Directories, did that make the "cannot open include file: 'brook/brook.hpp'" error go away?

Yes. It would be a big help to all, I assume, if this was included in the documentation if it's not already. I didn't see it in the Brook+ docs. Did I miss it somewhere?

Also, make sure BROOKROOT has been set properly. It should be been done for you with the installer. Go to Start->Run and run "cmd". Type: "echo %BROOKROOT%" and make sure it is pointing to C:\Program Files\AMD\BROOKPLUS SDK v1.00.0_alpha\

This was setup correctly by the installer, no problems there.

The include path is something you need to add to all of your projects manually. MSVS has no way of knowing you want that path in your include path vs. some other path. If it put it in automatically, you might end up getting conflicts between 2 different packages which have similarly named include files. Then, it would be which ever include path was first which wins. No desireable behaviour.

Again, if this is true it would be helpful if this was noted in the documentation, if it isn't already.

The only way for this to be automatically in your include paths would be if we installed Brook+ and CAL include files and library file directly into your MSVS directories which wouldn't be a very clean thing to do. We prefer to keep our files separate so it makes for easy updates, etc.

Understand . Once again, documentation would be very helpful.

Also, as far as the linking is concerned (the LNK2019 error), do you have Project Properties->Configuration Properties->Linker->Input->Additional Dependencies set to "$(BROOKROOT)\sdk\lib\brook.lib"? You need to make sure the double-quotes are there. BROOKROOT, as it is setup by default, has spaces in its resolution. This will confuse MSVS and it will end up thinking there are 2 dependencies there (it seems to handle spaces in the resolution of BROOKROOT for the include path for some reason).

Thank you, this took care of that problem. The documentation states to do it for the .br properties but doesn't say this must be done for the Project properties. Also, is the double quotes just a MSVS thing? I haven't really used MSVS that extensively until now. It would be helpful if the screenshot on page 9 of the Brook+ Programming Guide also had this line included.

Give that a try and let me know how it goes.

Thank you for your time.

Michael.
0 Likes

Totally agree that this should be in our documentation. I'm working with the engineering team to get our documentation improved and appreciate you bearing with us through our improvement stage! 🙂

And, my pleasure! 🙂 I'm always happy to see a customer and user of our tools get to a point where the tools are working for them. 🙂

Please don't hestitate to post any other questions you may have!
0 Likes
bonissent
Journeyman III

In the same field, probably a silly question : when trying to build the application (inside vs8), I have an error message about not being able to find windows.h . My understanding is that this can be found in the PlatformSdk, which I downloaded, tried to add it in the include path, no effect. I also tried (recommended somewhere) to copy the include directory from PlatformSDK into a directory internal to VS8, no success either. I see that my windows.h file starts with an uppercase W, does that matter? and if it does, where am I supposed to find the lower case one?
0 Likes

Are you only encountering this with Brook+ programs? Have you tried a simple program with only #include <windows.h> and a simple main function?

Under Windows, upper case and lower case shouldn't matter, I believe.

Michael.
0 Likes
bonissent
Journeyman III

Thanks for the advice, this was useful. The simple exercise helped finding the origin of the problem (a silly one of course). Now I am having trouble with flex. Get the message : flex is not recognized as an internal command.

I installed flex from the Win32 web page, but still get the same symptom. Is there something I should do to make sure that visual studio knows that flex is installed ?
0 Likes

Are you trying to recompile Brook+ itself? You shouldn't need to.

But, if you are, did you:
- make sure the path to flex was added to your system PATH variable? (try going to a cmd.exe prompt and typing flex)
- if that works, did you restart MSVS (it won't pick up PATH updates until it restarts).

Michael.
0 Likes
bonissent
Journeyman III

OK, this is slow progress!
I now understand that I am not supposed to build brook+ itself, just the applications. I am now at the point where I am able to build and run the examples included in the distribution, and even change them (a little) and see that the result is different.

Despite the amount of efforts it took to get there, this is not what I really need to do. I want to create my own brook+ project and this is where I do not understand the best method. So far I managed to create a new solution in my own VS space, then copy the hello_brook.br project into it, and finally make the appropriate renames to make it work again. However I do not think this is the recommended method.

Question is then :
how do I create a new brook+ project from scratch inside VS, with the adequate directory structure, compile options etc?
0 Likes

Sorry about not having more detailed instructions for setting up a new project! It's being worked on internally here.

In the meantime, here is an excerpt of instructions I gave another user in a private email:

You should just be able to setup the include paths, library dependencies and custom build command manually in the project.

First of all, I assume you are only trying to compile programs with Brook+... not actually try to rebuild Brook+ (since you shouldn't need to rebuild Brook+).

- You want to make sure that your include path is setup to be "$(BROOKROOT)\sdk\include" .
- You want to make sure that your additional library dependency is "$(BROOKROOT)\sdk\lib\brook.lib" . (The double quotes are especially important here since BROOKROOT tends to include "Program Files" and the IDE gets confused about the space when it expands BROOKROOT for some reason.
- You want to add your .br file to the sources.
- Right-click on the .br file to go to its properties and go to "Configuration Properties->Custom Build Step->General".
- Setup the "Command Line" to be: "$(BROOKROOT)\sdk\bin\brcc.exe" -o "$(ProjectDir)\built\$(ProjectName)" "$(InputPath)"
- Setup the "Outputs" to be: $(ProjectDir)\built\$(InputName).cpp

Then, do a build... it is going to fail since you only built the .br file which caused the .cpp file to get built. But it hasn't been added to the project yet so you are missing a main function, etc.

Now go and add the .cpp file that was generated (it should be in the project directory under built\) and build again.

That should result in a successful build. I just hand created a project from scratch today under Visual Studio 2008 and was able to make it work.
0 Likes
bonissent
Journeyman III

Thanks, this helped, I think I understand better now what is going on.
0 Likes

My pleasure and glad that it helped. 🙂

Please don't hesitate to post more questions if you encounter any other issues!

Michael.
0 Likes
bonissent
Journeyman III

Here is a new, maybe related problem : I would like to connect the brook+ code to a java application using JNI (the Java Native Interface). I think I know how to do it, even under windows. In fact I even have an application which works as long as it does not include the brook+ code. And I also have an application involving brook+ and my own c++ code. So far so good but here are the problems :

- jni needs perrforms dynamic loading, therefore I have to create a dll
- I create my object files with cl.exe and create a dll with link.exe
- For the jni without brook+ I believe I need the /MT flag (probably the default);
- If I include brook+ code, I believe I need /MD or /MDd otherwise there are conflicts with some utilities;
- But when I use /MD the dll cannot be loaded from java, the message being : Unsatisfied Link Errors, cannot find dependent libraries. Which library is missing remains a mystery; playing with the PATH env variable did not help.
- I also tried putting the manifest inside the dll (with mt.exe), with no success.

This may not be a Brook+ problem, but if it is maybe someone would have the solution.
0 Likes

Let me forward this off to the Brook+ team to see if they have any ideas.

Michael.
0 Likes
bonissent
Journeyman III

If they want more details, I have put some relevant files there :
http://marwww.in2p3.fr/~bonissen/pixscan/testjni.tar

There is a directory nobrook, which contains java code, c++ code and makedll.bat, the latter doing the compilation and link. There should be also a runit.bat to run the code. This one works fine but does not involve brook;

There is also a directory withbrook, which does the same but invokes some brook code. Again there is a makedll.bat for the compilation etc, and runit to run the java code, which fails because it cannot load the dll. However running the executable from ados window works fine, which proves that the problem is with the java native interface.
0 Likes

The team believes it is because the Brook+ runtime libraries were built with /MD instead of /MT. This should be fixed in the next release. Will you be able to make forward progress until the next release? Or is this a blocking item for you at the moment?

The other option is to recompile Brook+ with /MT from the provided sources.

Michael.
0 Likes
bonissent
Journeyman III

In fact this is where I am stuck at the moment.

I just tried the following :

- open the brook+ solution with visual studio;
- go to the general properties of runtime and change the Use of MFC to : Use MFC in a static library (was Standard Windows Libraries before);
- rebuild project

- In my compile and link bat file which I use to compile and link the code, I changed MDd to MT and replaced the ...AMD.../sdk/lib by the ...AMD.../platform/runtime/lib/xp86_32/

When I run this, I get error messages saying that _malloc, _calloc, _realloc etc... already defined in LIBCMT.lib(malloc.obj) for instance.

Does that ring a bell?
0 Likes

Hi bonissent,

I haven't tried that but did you try just changing the /MD to /MT? If you rebuild runtime using /MT and do the "Release" version, does it work?

I just rebuilt the "Release" runtime with /MT under Configuration Properties->C/C++->Code Generation and it completed.

Michael.
0 Likes
bayoumi
Journeyman III

Hi,
In case this helps, I ran into similar issues before when linking old linux C code to Brook under Windows XP 32. I always got redefinition issues between CMT.lib & msvcrt.lib & brook.lib. I only got it solved when I got rid of CMT.lib, and used only the msvcrt.lib + brook.lib+ User32.lib (and the kernel32.lib). I always had to keep the -MD flag.
Try if your code can compile without CMT.lib in the link list, and use some other lib that has the same functions. For external references that ask for CMT.lib, try to search the help within VC2005. Sometimes they are found in other libs beside CMT.
This is not a very scientific answers, but with software sometimes trial & error is only way left to try
0 Likes
bonissent
Journeyman III

Thanks to both for the advice. With pain I managed to rebuild brook runtime with the static libraries (the command line says MT) from inside VS2005. THere is an error when building brcc but I think I can safely ignore that for the moment (I use the standard one).
Then I have a standalone bat file to do the compilation. It uses runtime for the brookplus sdk libraries in the link step.

I also added msvcrt.lib in the list of libraries at the end.

There are now 3 messages LNK4098 which say that LIBCMT, MSVCRTD and LIMCMTD conflict with other libraries, and recomment saying /NODEFAULTLIB but if I do that, there are many unresolved references. I suspect that in this case I would have to list all necessary libraries, of which I have no idea. I would be happy to try removing LIBCMT (and maybe the other 2 as well), but how can I do that without the /NODEFAULTLIB ? which is probably overkilling. How do I even know what is the conflict?
0 Likes
bayoumi
Journeyman III

Hi Bonissent,
please look into the help topic from VC2005: use help -> search -> linker options -> /MD (click on it)

It says if you use /MT, you might still need the LIBCMT.lib. In my case I was using /MD, so I mainly wanted the MSVCRT.lib. I also see you have conflicts from LIBCMT.lib & LIBCMTD.lib at the same time. I think they are the same, with one being the debug version. I "think" you should be using only one of them, but not both at the same time. Here is the help text on it:

/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.

Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR80.DLL, which must be available at run time to applications linked with MSVCRT.lib.

When /MD is used with _STATIC_CPPLIB defined (/D_STATIC_CPPLIB) it will cause the application to link with the static multithread Standard C++ Library (libcpmt.lib) instead of the dynamic version (msvcprt.lib) while still dynamically linking to the main CRT via msvcrt.lib.

/MDd
Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file.

/MT
Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.

/MTd
Defines _DEBUG and _MT. This option also causes the compiler to place the library name LIBCMTD.lib into the .obj file so that the linker will use LIBCMTD.lib to resolve external symbols.


If you want to get rid of a library, use /NODEFAULTLIB:librarypath. Please see help->search->linker options - /NODEFAULTS

I hope I am not confusing you, since I am not from the official AMD team
regard
Amr
0 Likes
bonissent
Journeyman III

Unfortunately I cannot remove the message above, for which I am a little confused. Now I know how to use /NODEFAULTLIB, and I also discovered that one needs to have all modules compiles as nodebug and with the same MD, MDd, MTd or MT. I use /MT for all and eliminate CMT and MSVCRTD with NODEFAULTLIB. Also use the brook library prepared from VS2005 with MT. With all that the compilation and link goes well and a dll is produced.

Unfortunately, the Java Native Interface is unable to load it because it does not find some dependent library (does not say which one).

Related questions :

- Is it true that a dll is self contained ? or may it require loading an other one ? (seems to be the latter);
- Is it possible to control the above ? I mean force a fully static dll which would contain all necessary references, even if it is bigger;
- If I cannot control, can I at least know which other dlls my own dll depends on? I tried the dependency walker but could not make any sense of it!
- Doe s brook involve dlls apart from amdcalcl and amdcalrt, which I already included (dis not help);

Thanks for the help
0 Likes
bayoumi
Journeyman III

A quicknote: I thought if you used /MT you should keep LIBCMT.lib & remove LIBCMTD.lib. I also had the same problem when I generated OK an exe file using the /MDd (debug option) which comes with sample code, but I was linking it against non-debug lib. You finish the linking OK, but keeps ask me during runtime for missing DLL (Debug related)
Please make sure first of this item, since the linker will not catch it
Amr
0 Likes
bonissent
Journeyman III

You must be right, however when I try excluding libcmtd, the linker message is that libcmt conflicts with some other libs, but does not tell which one(s). Could it be that jni is linked by default with debug? in which case there is not much which I could do.
0 Likes
bayoumi
Journeyman III

maybe try to compile your own code with Debug options to see if this was the issue
Amr
0 Likes

I continue to get LNK2005 errors, but only when I build my solution. It says that "my_function" is already defined in "filename".obj

I have created a "wrapper" file, that is I have a .cpp with my main and a .br file, I then call the created br->cpp file from my main cpp file. If the solution is trying to build all of these will this create an already defined? I mean, there is a "my_function" in the .br file and then again in the created br->cpp file.

How do I get around this?
0 Likes

Originally posted by: ryta1203

I continue to get LNK2005 errors, but only when I build my solution. It says that "my_function" is already defined in "filename".obj



I have created a "wrapper" file, that is I have a .cpp with my main and a .br file, I then call the created br->cpp file from my main cpp file. If the solution is trying to build all of these will this create an already defined? I mean, there is a "my_function" in the .br file and then again in the created br->cpp file.



How do I get around this?


I just removed the br->cpp file from my project but kept the #include"br->cpp file" in my main cpp file. This solved the problem, just thought posting this might help others.
0 Likes


The release notes for 1.00.2 Beta states that gcc for linux is supported, yet there is no FirestreamSDK download for linux. Am I missing something?
0 Likes

I apologize for this slip up!

gcc/g++ 4.1.2 is what will be supported in the next release for Linux. The engineer writing the release note just got a little ahead of himself. 🙂

Michael.
0 Likes
bonissent
Journeyman III

Thanks for the effort. My conclusion at this point is that developing under windows is not for me, maybe I am not intelligent enough. Other conclusion is that there must be some incompatibility between jni and c++ under windows and trying to fight against that is a waste of time. I am now exploring a client-server solution, hoping better success.
0 Likes