On 1/25/13, Charles Landau <[email protected]> wrote: > Matt, IIUC, you are proposing: > > 1, The developer has a PC running his favorite flavor and version of Linux. > 2. Under that system there is a VM running Fedora Core 10 (the latest > version that I know has working cross-compilers). The developer compiles > and perhaps develops on that system.
I was actually wanting to update them to a newer fedora, I'm currently running them patched on fc16, but willing to update the cross-compilers for whatever version we decide upon, and upload a fork of the existing tools including the patches and scripts to build the image to a repository. In other words, I'm already maintaining them locally, and trying to figure out a decent way to distribute them that doesn't require me to compile them for a bunch of different fedora versions, something i can preferably sign and stick on a file locker. In fact updating them will make it a lot easier given the newer fedora image generation tools. I suppose it comes down to: i'm far too lazy to generate them the way shap did, the excess compiles every time the tools change or fedora releases a new version would make me dread rather than enjoy doing it. I suppose what I should probably do, is just try it once it see if it works for everybody or not, and then we can decide? > 3. There is probably a second VM for running x86 CapROS. right, I also do a 3rd VM running CapROS-arm running under emulation on x86. though it doesn't quite get to executing user mode instructions yet I kind of have ignored this part because it's something that should probably happen on the developers (1) machine rather than having to deal with nested vm's. > I don't understand what you are proposing with a loopback device. we can drop this from the discussion if you would like. it's somewhat orthogonal. but because grub-install/fdisk want to work with /dev block devices to create bootable partitions etc, and that requires root, or fiddling with permissions/groups something unacceptable when building on the developers (1) machine, that would typically be documented as 'post compile instructions', but could be done on a vm with no harm, but some extra copying/disk usage. so it's just something that could make the above (3) images easier to build. > #2 would be essentially the same as the Linux development system I use, > except mine is on a real PC. > > One downside of this is that CapROS builds would remain stuck on the > FC10 tools and wouldn't be able to take advantage of any subsequent > progress. hopefully answered this above. > What about this alternative: Use the (non-cross x86) tools (compiler and > libraries) that come with the current version of Fedora Core (might work > on other Linuxes too). We would lose the features that CapROS adds to > the current cross tools. There are two that I know of: I suppose, I mean keynix showed it could be done I think its going to be a lot more work than just banging our existing compilers in to shape, and might end up like a swan dive into the la brea tar pits :-) > 1. The regular C libraries have procedures such as read() and open() > that make system calls designed for the host system (e.g. Linux). CapROS > does not support these and the CapROS cross libraries do not have them. > The difference would be that if your program attempts to use these > procedures, you will get a runtime error (crashed process) instead of a > link-time error. On the plus side, sprintf() might work and xsprintf() > and kprintf() would be eliminated or simplified. > > 2. There are some modules (in src/base/lib/domain/crt) for > CapROS-specific runtime initialization. CapROS Makefiles would have to > be modified to explicitly include these modules when linking. This > should not be hard because linking is done with Make macros. _sbrk() and > _exit() do need to be supported, and the CapROS versions could be > explicitly linked before scanning the C library. > > Am I missing any other issues? i think also disable the crt0 that come with the linux compiler as they probably wouldn't play nice. the pain doesn't really stop there, when porting anything alien that uses configure will recognize it as a gnu-linux compiler, and do the wrong thing too. > This doesn't solve the problem of getting modern tools for developing > CapROS for the ARM target, but it might make it easier, because it's > easier to build cross tools if you don't have to integrate the > CapROS-specific stuff (try Googling "cross linux from scratch"). right, its a lot of pain for a partial solution. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ CapROS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/capros-devel
