Bob Friesenhahn wrote:
On Thu, 11 Sep 2003, Guido Draheim wrote:
* short
The world has changed - there are commandline tools for unixish systems that take a C program (not C#!) and compile them into a MSIL binary or library. This makes it a valid crosscompile target for free software.
Your very *long* posting failed to describe in which way the dotnet
target varies from traditional targets. Microsoft's Visual Studio
handles building for .net very similarly to traditional binaries. It
uses "normal" object files and "normal" DLLs. These apparently
"normal" files have had their format extended to support .net.
The nt/win9x exe/dll are container formats based on the pe/coff format. The coff (common object file format) format is widely used and especially not in windows based operationg systems (e.g. palm-coff). The gnu binutils do reuse some coff handling routines to access pe/exe binaries. Not to be confused with the oldish ne/exe format of win3/dos binary origin, those are not handled by gnu binutils AFAIR.
Similar to elf container format different sections may be put into them and marked as executable for a target machine. The dotnet extensions add an executable section containing IL code to be executed by the dotnet machine, often compiled onthefly to the target cpu native code. On a whole, IL is another cpu type, better described with ISA, instruction set architecture. Not known to many, the windows operating system can run on different cpu types and the microsoft compilers can generate pe/coff exe/dlls to contain native code for these ISA types, e.g. i386 or ARM native code. With dotnet, an IL intermediate code is put in. Some other binary sections are added as well describing the class container in more detail, similar to sharedlib exports/imports.
> For the C language, Microsoft's Visual Studio is able to link with
traditional binary libraries. If the Unix dotnet target uses a similar paradigm, then compiling for dotnet could be as simple as adding some CPPFLAGS, CFLAGS, LDFLAGS, and LIBS, options.
I can not answer that easily, I have no real experience in this. AFAIR, the microsoft compilers can build an importlib for existing native code. I have no knowledge on that status in the existing free dotnet implementations, it may have to do with `unmanged code`. IIRC, the dotnet IL code is designed to call into native code for function call imports.
What does compilation of a dotnet library (.net assembly) and compilation of dotnet dependent programs look like under Unix?
The mono and pnet sites have examples for simple helloworld type programs along with the commandline to be used to compile them and to run them. As mentioned earlier, the csc mono compiler is commandline compatible with ms dotnet, while the cscc pnet compiler is gcc compatible. A simple `cscc mysrc.c -o mysrc.dll` looks very similar to unix traditional invokations - the .dll extension will trigger the requirements for a dotnet library but there should be enough compiler options to enable/disable each part explicitly.
cheers, -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
