On Sat, Mar 16, 2013 at 11:12 PM, Jonathan S. Shapiro <[email protected]> wrote:

> I want to describe what is being done, but I also want to explain why we are
> not adopting the "builld it yourself" approach that Matt Rice suggested back
> in January.

hmm, I see I mentioned the 'everybody builds a toolchain' model,
I didn't intend to advocate it, I don't really like it for all the
reasons you have given, I only really mentioned it for the sake of
completeness.

I think a centos vm is closest to what I was advocating, and the path
of least resistance from where are.  So I am definitely willing to go
alog with that route.  What follows is just a little update of what I
was looking into before this decision just for the record...

---

 I spent a little time evaluating small self hosting distros, and
kinda settled on www.baserock.org as the ideal VM for me at least.  in
that It's minimal and uses sources directly from version control (git)
which helps manage the capros/coyotos specific patches to the
toolchain,
 It has a way (with the trebuchet tool) that we can provide a delta
containing the cross compiler tools that gets applied to the standard
image.  The main issue is it is currently undergoing a rather furious
development pace I was hoping to attack it once it settles down
somewhat.

At that point I started evaluating the toolchain itself, with a focus
on coyotos/capros eventually self hosting.   Without posix emulation I
don't think it'll ever run the GNU tools filenames are ubiquitous
throughout all of them, with the bfd library wanting to
open()/close().

so I started to look into llvm and outside of the pesky libstdc++
dependency, the linker scripts here are the main impediment to
complete self hosting, as the llvm tools don't really have any linker
scripts, relying on gnu tools for that.  which means at least for
compiling the kernel we need gnu tools, still having the ability to
compile normal executables would be great.  The llvm tools themselves
appear to generally leave filenames at the main() level
so they seem much more straightforward task to port.  so I started
looking into the various standard c++ libarary implementations
which is about where I ran out of steam for the time being.
Definitely not the path of least resistance.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
CapROS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/capros-devel

Reply via email to