Archives Discussions

[jean-claude]

converting a working code (tested on the previous SDK version) to 1.3

I get the following compile/link error :

error LNK2019: unresolved external symbol "public: static class brook::Runtime * __fastcall brook::Runtime::getInstance(void)" (?getInstance@Runtime@brook@@SIPAV12@XZ) referenced in function @__sti__$E@0

I honestly don't have a clue on what this __sti__ or runtime::getinstance is????

Could you please help on this one ??

Thanks

[gaurav_garg]

These linker errors can be because of the following reasons-

1. Still linking with old libraries. Make sure BROOKROOT is properly set.

2. Trying to link 32 bit applications with 64-bit libraries and vice-versa.

Make sure you have installed 32-bit installer if you want to build 32-bit applications.

Let me know if it helps.

[jean-claude]

Hi Gaurav,

Thanks for your support. Here is the status:

Environment : Vista 32, Visual Studio 2008, using iIntel C++ Compiler

(1) BROOKROOT set to C:\Program Files\AMD\AMD Brook+ 1.3.0_beta

(2) Using 32bit libs (located in C:\Program Files\AMD\AMD Brook+ 1.3.0_beta\sdk\lib)

(3) Successfull re-generation of 6 others brook programs (using old brook syntax)

(4) BTW: Tried to rebuild brook runtime ( partially failed see subject:  http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=104696&enterthread=y )

(5) Now coming back to the core issue I'm experiencing with my project :

still have this error

LNK2001: unresolved external symbol "public: static class brook::Runtime * __fastcall brook::Runtime::getInstance(void)" (?getInstance@Runtime@brook@@SIPAV12@XZ)

Tried compile with brook.lib and the brook_d.lib .. no more success

- Is there any lib reference missing???

- Is that somewhat related to c calling convention??

I'm stuck on this one, thanks for your help

[gaurav_garg]

HI jean,

The reason I can think of this error is that brook runtime is built using cl compiler and you are are building your application with iIntel compiler and both the compilers can have different name-mangling conventions for functions.

It will be a good idea for you to try building Brook+ runtime on your end using the same compiler.

You can build Runtime on vista machine if you go to project settings and change  Additional Library Directory settings to $(CALROOT)\lib\lh32.

[jean-claude]

Hi Gaurav,

Maybe an interesting hint: when I try to recomplie Brook run time this is

a warning that I get

1>Runtime.cpp
1>.\Common\Wrappers\Runtime.cpp(139): warning #1786: function "getenv" (declared at line 447 of "C:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdlib.h") was declared "deprecated ("This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.") "
1>              rRuntime = getenv("BRT_RUNTIME");

This maybe means that there is an overlap with another getenv function ???

BTW. I additionally noticed that some issues were raised on singlequestioncolon stuff, se below :

C:\Program Files\AMD\AMD Brook+ 1.3.0_beta\platform\runtime\\..\include\brook\CPU/brtvector.hpp(99): warning #864: extern inline function "singlequestioncolon(const B &, const T &, const T & [with T=vec<double, 2U>, B=vec<double, 2U>]" was referenced but not defined
1>  template <> inline vec<double,2> singlequestioncolon (const vec<double,2> & a,
1>                                   ^
1>
1>C:\Program Files\AMD\AMD Brook+ 1.3.0_beta\platform\runtime\\..\include\brook\CPU/brtvector.hpp(96): warning #864: extern inline function "singlequestioncolon(const B &, const T &, const T & [with T=vec<double, 1U>, B=vec<double, 1U>]" was referenced but not defined
1>  template <> inline vec<double,1> singlequestioncolon (const vec<double,1> &a,
1

[jean-claude]

Finally, I found some turn-around trick ...

For our friends users of Intel C++ compiler, beware of
the following gotchas

(1) icl automatically overriding '/Gd' with '/Gr'
(2) use of global program optimization
(3) use of parameter Multi-file (/Qipo)


What has been going on is that for a strange reason, icl
was forcing function call to be _fastcall.

brook::Runtime::getInstance(void) is expected to be _cdecl.

After some black_magic tuning of icl compiler flags... the issue
seems to be cleared.

I have to admit I don't really understand and get the whole picture...

Hope this could help one of you guys if falling in a similar sandtrap!


BTW. Through this painful process I took advantage of the very handy
tool InspectExe that shows all import and export functions of an executable file
(.EXE, .OCX or .DLL) or .LIB
  ( http://www.programfiles.com/Default.asp?LinkId=5378 )