Re: dotnet platform support / gnu config.sub (long)

[Guido Draheim]

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-