<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>ARM_DARWIN I never quite finished.<div>It was almost working on a jail-broken iPhone 3gs.</div><div>Setting up and testing just a C development environment</div><div>is often the difficult part.</div><div><br></div><div>If you do have a C cross compiler yes that can shift slightly,</div><div>easily where some things happen.</div><div><br></div><div>Let me explain.</div><div>The compilation process has a few different steps it can go.</div><div>Including that we have some C code.</div><div>So that goes .c => .o, or internally .c => .s => .o.</div><div><br></div><div>Ignoring LLVM...</div><div>We have the NT386 backend.</div><div>Code goes right from .m3 => .obj.</div><div>cm3 does "everything".</div><div><br></div><div><br></div><div>We have the gcc backend.</div><div>Code goes</div><div>.m3 => .mc => .ms => .o</div><div><br></div><div><br></div><div>.ms files are just assembly source</div><div>.mc files are an internal format that cm3 writes out.</div><div><br></div><div><br></div><div>We have the C backend.</div><div>Code goes</div><div>.m3 => .c => .s => .o</div><div>cm3 writes the .c files.</div><div><br></div><div>And then there is linking.</div><div><br></div><div><br></div><div>This is all *hightly* automated.</div><div>From the users point of view, cm3 seems to go from .m3 files to a .a/.dylib/executable.</div><div><br></div><div><br></div><div>But cm3 only has within it some of the stages.</div><div>It doesn't have a C compiler, an assembler, or a linker.</div><div>We depend on a "C" toolchain for this (I'm calling assembler/linker part of the C toolchain).</div><div><br></div><div>If you don't have the C toolchain, then you are stuck part way through those pipelines.</div><div>Either with a bunch of .o files you can't link.</div><div>Or a bunch of .ms files you can't assemble and link.</div><div>Or a bunch of .c files you can't compile/assemble/link.</div><div><br></div><div><br></div><div>Native toolchains are historically more common than cross tool chains.</div><div>So we have a "boot" workflow -- that needs work -- where on the "first" machine,</div><div>you stop where I say you are "stuck", you archive up the files, copy them</div><div>to the target machine, which has a native toolchain, and then resume the pipeline --</div><div>running C compiler/assembler/linker.</div><div><br></div><div>Now, if you have a cross toolchain there is not quite reason for that.</div><div><br></div><div>But, it comes down mainly to the config files and the builder, and another detail I'll get to.</div><div><br></div><div>The "boot" workflow was well automated 20 years ago.</div><div>Back when "quake" was written in C. The 3.6 release.</div><div>I don't remember what the 4.0/4.1 release looked like.</div><div><br></div><div>I have good automated flow for producing a cm3 for cross scenarios,</div><div>and it is useful, but it requires a matching source tree on the other side.</div><div><br></div><div>This is boot1.py and boot2.sh.</div><div><br></div><div>If there is an incompatibility, like I recently added to m3core, then it doesn't work.</div><div>So it dawns on me now, that boot1.py should produce m3core/libm3, and maybe cm3cg.</div><div>Though cm3cg would require a cross compiler, so sometimes a pain.</div><div><br></div><div>"another detail I'll get to".</div><div>We have a small number of tools that when we build the system, we build</div><div>them and run time. Other than cm3. There is mklib, which I already handle.</div><div>But there is also m3bundle and PklFonts and some RPC stub generators.</div><div><br></div><div><br></div><div>Given a cross C toolset, we don't have conventions/automation around,</div><div>hey, I'm targeting x, building on y, my y-hosted tools might need an update.</div><div>I need to build all of y, then all of x, and when I'm building x, what is the cm3</div><div>I use? What is the C compiler I use?</div><div><br></div><div><br></div><div>Again it is mostly just a thing with config files.</div><div>The config files tend to run "gcc" and find it in $PATH.</div><div>They assume it is for the current host/target.</div><div>But there needs to be arguably some convention, I'm hosting on I386_LINUX,</div><div>targeting AMD64_DARWIN -- where are the native tools and where are the cross tools?</div><div>In gcc-land, this is basically you run ad64-apple-darwin-gcc for the AMD64 target toolset,</div><div>instead of just "gcc"</div><div><br></div><div>You might also run e.g. /usrl/ocal/cm3/bin/<target>/cm3cg.</div><div><br></div><div>So, very long story short -- we largely need a file system layout.</div><div><br></div><div>The "GNU platform" mapping I386_DARWIN => i386-apple-darwin8 for example,</div><div>is somewhat encoded in our tree, but for this to work it needs more formalization.</div><div><br></div><div><br></div><div>With LLVM, you get all the backends together in on tree and you give</div><div>the executable a command line switch and it finds the right .so, I imagine,</div><div>so this sort of gets easier. We still have to know the switches and work that into config and such.</div><div>We should just do that for native targets anyway and then cross will reuse that.</div><div><br></div><div>Again, sorry, long story short -- paths and switches to compiler/assembler/linker is largely the thing.</div><div><br></div><div>Apple has a good system here btw.</div><div>You say gcc -arch ppc.</div><div>And that combines with -x assembler.</div><div>So you can cross compile with gcc -arch ppc.</div><div>You can cross assemble with gcc -arch -x assembler.</div><div>They put the work in the gcc driver. It then farms out to the correct cc1/cc1plus/as.</div><div><br></div><div><br></div><div><div>If only this was the norm..</div></div><div><br></div><div><br></div><div>Another thing -- a cross C compiler that can handle something with no #includes and</div><div>no linking, is really easy to build. It is the headers and libraries that make it more difficult.</div><div>The assembler/linker are also sometimes a sticking point, because sometimes, if you</div><div>read the gcc config/install manual, they prefer the native closed source assembler/linker.</div><div><br></div><div><br></div><div>I have a working VMS C cross compiler from Mac, but I had to copy various files</div><div>from a running VMS machine to do it -- the headers and libraries.</div><div><br></div><div><br></div><div>In as much as the assembler/linker is GNU, it is easier.</div><div>And Apple's stuff is open source and people have ported it.</div><div>But imagine targeting HP-UX or AIX, or NT using the Microsoft toolset.</div><div>There you can't just conjure cross tools with arbitrary host, only what the vendor ships.</div><div><br></div><div><br></div><div><br></div><div> - Jay<br><br><br><div><hr id="stopSpelling">Date: Fri, 14 Aug 2015 09:30:16 -0700<br>From: lists@darko.org<br>To: m3devel@elegosoft.com<br>Subject: Re: [M3devel] Build Server - Plan<br><br><div dir="ltr">What hardware setup did you use to ARM_DARWIN? I want to support ARM too. I'm not sure if a separate ARM server is in order, or a QEMU setup. I can just plug some Apple hardware into a USB port if that works. Maybe a cross compiler is the best solution.</div><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On Thu, Aug 13, 2015 at 11:36 PM, <span dir="ltr"><<a href="mailto:microcode@zoho.com" target="_blank">microcode@zoho.com</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;"><span>On Thu, Aug 13, 2015 at 01:27:54PM -0700, Darko Volaric wrote:<br>
</span><span>> I'm setting up a server for building CM3 that takes a "minimalist" approach.<br>
><br>
> It's a machine running several virtual machines, one for each platform<br>
> supported by CM3. Each VM will contain clean install of the OS plus any<br>
> external tool dependencies. It will have a minimal compiler install,<br>
> basically enough to compile itself for the host target.<br>
<br>
</span>Doesn't CM3 support Solaris SPARC? As far as I know there is no cheap way to<br>
emulate this from Intel.<br>
<span><br>
> The publicly available build products will be:<br>
><br>
> - minimal executables for bootstrap, eg the frontend and a backend<br>
> - model compiler config files<br>
> - compilation logs for bootstrap executables<br>
> - compilation logs for most modules in the github repository<br>
> - logs for certain tests<br>
<br>
</span>This sounds like a setup for experts. Why not make a turn-key tarball<br>
available like was available (I think) before?<br>
<span><br>
> Packages, libraries, scripts and non-essential tools or executables will<br>
> not be built or used, the idea being that people take the minimal<br>
> bootstraps and build from there.<br>
<br>
</span>That's fine for the 3 or 4 core guys doing all the work! For everybody else<br>
this is a big inhibitor to making CM3 generally useful to the rest of the<br>
world- unless the instructions to get a complete install are very clear and<br>
easy to follow. But it seems from watching the discussion here it is<br>
non-trivial to get CM3 installed.<br>
<div class="ecxHOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><br>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</div></div> </div></body>
</html>