Thanks Barry. This was helpful
Chris
On Sun, 6 Jul 2003 09:50:55 -0700, Barry Bond <[EMAIL PROTECTED]>
wrote:
>There are a bunch of small things to do...
>
>- edit sscli/clr/src/dirs and add Type1 to the list of directories.
>This is what build.exe uses to determine what subdirectories to recurse
>into.
>- in your new sscli/clr/src/Type1 directory, copy "sources" and
>"makefile" from sscli/clr/src/tools/ildbsymbols - they build a
>reasonably bare-bones DLL so they're a good place to start.
>- edit the sscli/clr/src/Type1/sources file, changing:
> - TARGETLIBNAME - this contains the base filename of your DLL
> - COFFBASE - also set this to the base filename of your DLL
> - DLLDEF - specifies the name of the .DEF file to use
> - DLLENTRY - specifies the main entrypoint into your DLL (ie.
>DllMain)
> - SOURCES - lists all C/C++ files that are to be compiled into
>your DLL
> - LINKLIBS - lists the .LIB files to link against, other than
>the default ones that all EXEs and DLLs
> link against. For your DLL, it should probably be empty
>- edit all three
>sscli/clr/bin/rotor_x86/{checked|fastchecked|free}/coffbase.txt files
>and add your DLL into the list. These files control the preferred base
>addresses of DLLs.
>- edit sscli/rotorenv/bin/placefil.txt and add your DLL to the list,
>with ".dll", ".dylib" and ".so" extensions. The second column in the
>file specifies the destination directory that binplace should put the
>file in - you'll want "retail", which translates to %TARGETCOMPLUS%, the
>same as sscoree.dll's destination.
>
>That will get your DLL into the build. To reference it from another
>DLL, like sscoree.dll or mscorejt.dll, edit the sources file that
>creates the DLL (sscli/clr/src/dlls/mscoree/sources.inc or
>sscli/clr/src/fjit/sources) and add your DLL's .lib file to the
>TARGETLIBS list.
>
>All of these steps were derived from grepping the tree for "ildbsymbols"
>- it is often easier just to copy some part of the project that already
>works and edit, rather than starting from scratch.
>
>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: Saturday, July 05, 2003 10:18 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [DOTNET-ROTOR] Accessing the class in different source
>folder
>
>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
Thanks Barry; this was helpful
Chris
