<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
> From: <a href="mailto:hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a> <BR> <BR> > I wasn't using the CVS tree. I was using <br> > cm3-src-all-5.8.6-REL.tgz, downloaded from <BR><br> <br> cm3-src-all-5.8.6-REL.tgz really ought to work. <br> But I don't know. <br> I can try later. <br> <br> <br> <br> > That's what I'll do. Is the current head in good <br> > enough shape? <BR> <BR> I think so, but please try it, and we'll see. <br> I've actively using it lately (working on moving to gcc 4.6, making good progress) <br> <BR><br> > So you compile the gcc backend. Presumably cross-compile <br> > it if necessary. Does gcc on one platform also produce <br> > object code for another? Or does the script custom-pick <br> > the backend depending on the target platform? <BR><br>It works. Trust me. Try it.<BR> <BR> Details:<br> <br> if you read m3cc/src/m3makefile, you see that "build_dir" is either "." or "../<host>-<target>" <BR> "." is really host or target -- the same thing, for a native build. <BR> cm3 automatically creates and cd's into it, rending it as just ".". <BR> <BR> We configure gcc appropriately (--host, --target) and run the cm3cg by full path, as I recall. <BR> <BR> We aren't cross-compiling gcc. We are building a cross-compiler. <BR><br> The following is confusing, but makes sense once you get your head around it: <BR><br> There are potentially up to 3 machines: "build", "host", "target". <BR><br> "build" is the machine you are sitting on "now". The one you are building the compiler on. <br> The machine you are building the compiler on. <br> "host" is the machine that the resulting compiler will run on. It will "host" the compiler. <br> "target" is the machine that will run the compiler's output -- that the compiler will "target". <BR> <BR> In common practise, all 3 are the same and things are nice and simple. <br> <BR> <br> But it can be that any two of three are the same or that all three are the same.<br> <BR> In the context of the Modula-3 build scripts, build and host are always the same. <BR> <br> <br> When host and target are different, that is a cross compiler.<br> When build and host are different, you are cross compiling the compiler. <br> When all three are different, you are cross compiling a cross compiler. <br> When build and target are the same but not equal to host, I don't know a term for that, I call it "cross back" -- you are building a compiler that will run on a different system but which will produce code for the system you are building it on. <br> <br> <BR><br> The challenge in various "cross " scenarios is having/getting the headers and libraries (libc) and linker and assembler, <br> and related, building libgcc2. <br> Often-times but not always, the GNU linker/assembler help. <br> Sometimes GNU libc helps. <br> But I for example haven't been able to build an ia64-linux toolset, due to the headers/libraries. <BR><br> <br> Building the C frontend/backend (and gcc driver for that matter) for build==host is actually always very easy. <br> <br> <BR><br> If you program is just:<br> int add(int a, int b) { return a + b } <BR> <BR> <BR> and you have gcc source, it is easy to convert it to assembly for any target,<br> without any headers/libraries/linker/assembler. That is all Modula-3 uses gcc for. <BR> <BR><br> But throw in an #include <stdio.h> or try to link to anything, and you need a lot more. <BR> <BR> <BR> In the Modula-3 system, how it was mostly structured at the start, and now, we cheat. <br> "final compilation/assembly/linking" can be deferred to the target system, which is <br> dependend upon to have a working native toolset. That is what my "bootstrap" archives do.<br> That is what the "bootstrap" archives of olden times (circa 3.6/1996) did I believe. <br> Also quake was written in C back then. <BR> <BR><br> Targeting something like iPhone/iPad doesn't fit...except that C cross tools are available <br> enough, so the same structuring works fine. <br> You typically just have to run different toplevel gcc/ld or add a switch like gcc -arch arm. <BR> <BR> <BR> We also cheat these days in that where #include <stdio.h> (for C runtime/kernel) was needed, I rewrote the code in C. <BR> This protects us from stdio.h changing or varying per-target. It was a big porting and maintenance and safety problem. <BR> <windows.h> and <Xlib.h> we still clone in Modula-3. They don't change so much. But maybe we should <BR> do something different there too. <BR><br> <BR> Make some sense? <BR> <BR> <BR> <BR> - Jay <BR> </div></body>
</html>