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
