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
