Thanks Barry; this helps. Can you/someone shed some light onto my
next/second question: I want to limit my code into a separate folder and
expose it as dll to Rotor core. What changes should I do to Rotor make to
detect this new directory (say clr/src/Type1) and build it as dll which
will be used in the similar way as mscorejit.dll.
I could not infer it from previous reply or from sscli/docs. Thanks
Chris
On Tue, 1 Jul 2003 04:52:15 -0700, Barry Bond <[EMAIL PROTECTED]>
wrote:
>The fjit directory builds mscorejt.dll, while clr\src\vm builds
>cee_wks.lib, which is consumed by clr\src\dlls\mscoree to build
>sscoree.dll. On Windows, each DLL has its own private namespace for
>types and functions, with ".def" files controlling what names are made
>available to other DLLs.
>
>In addition, mscorejt.dll does not link against sscoree.dll: the
>linkage is one-way, from the EE to the JIT. Sscoree.dll loads
>mscorejt.dll dynamically (via LoadLibrary), then calls GetProcAddress to
>look up the getJit() function address and calls it. This is the one
>place where function pointers and data are exchanged between
>mscorejt.dll and sscoree.dll, via the ICorJitInfo and ICorJitCompiler
>interfaces.
>
>The following steps are based on the pattern used already between the EE
>and the JIT - I used ICorDynamicInfo:getHelperFtn as the reference,
>since it is implemented in the EE and called by the JIT:
>- add a new "ConstructMyType" method to the ICorJitInfo class:
> - in clr\src\inc\corinfo.h, add the following method declaration
>to class ICorDynamicInfo:
> virtual Type1* __stdcall ConstructMyType1(void);
> - in clr\src\vm\jitinterface.h, add the following method to
>class CEEInfo:
> virtual Type1* __stdcall ConstructMyType1(void);
> - in clr\src\vm\jitinterface.cpp, implement
>CEEInfo::ConstructMyType1:
> Type1* __stdcall CEEInfo::ConstructMyType1(void) {
> return new Type1();
> }
>- from within the JIT, call compHnd->ConstructMyType() to create the
>Type1 instance.
>
>If you have declared all methods in Type1 virtual and keep all data
>private/protected, then everything will work without having to link
>mscorejt.dll against sscoree.dll.
>
>Barry
>This posting is provided "AS IS" with no warranties, and confers no
>rights.
>
>-----Original Message-----
>From: Discussion of the Rotor Shared Source CLI implementation
>[mailto:[EMAIL PROTECTED] On Behalf Of Chris
>Sent: Monday, June 30, 2003 9:27 PM
>To: [EMAIL PROTECTED]
>Subject: [DOTNET-ROTOR] Accessing the class in different source folder
>
>2 related questions on building the rotor with my source files. I added
>few of my own files to src/fjit folder; they can build and run well if I
>call into them from the file in fjit folder (I tested it by calling from
>fjit.cpp). As per my requirements however, files in core folder has to
>communicate with my code in fjit folder. This is where I am running into
>linker errors. I have following declarations in jitinterface.JITFunction
>
>Type1 t1;
>Type1 *t2=new Type1( );
>
>
>Type 1 is defined in file Type1.cpp in fjit folder. 2 Error mesgs that I
>get are error
>LNK2019: unresolved external symbol "public: virtual __thiscall Type
>1::....."
>
>Are these errors because I have to link Type1.obj with the Core? If so,
>how can I do it. Either way, please elaborate.
>
>My second question is: since all my code is independent of code in fjit
>folder anyway, what changes (and how) I have to do in "make" so that I
>can
>keep all of my code in a separate folder under "src" and yet compile and
>link it with Rotor in the usual way. Thanks in advance for
>clarifying....
>
>Cheers
>Chris
Thanks Barry; this helps. Can you/someone shed some light onto my next
question: I want to limit my code into a separate folder and expose it as
dll to Rotor core. What changes should I do to Rotor make to detect this
new directory (say clr/src/Type1) and build it as dll which will be
consumed in the same way as mscorejit.dll.
I could not infer it from previous reply or from sscli/docs. Thanks
Chris
