On 1/25/13 7:29 PM, Matt Rice wrote: > 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.
So IIUC you are saying we (that is, you) can still update the tools to newer versions (using a mechanism that I don't understand but that works for you) and release them to others (using a mechanism that you are working out now), but you can do it on a schedule that is independent of (and less frequent than updates to) the distribution and version of the Linux on the host PC. > 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? That seems like the best plan. >> 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 :-) The work I know about doesn't seem like a lot, but the work we don't know about could be a tar pit. > i think also disable the crt0 that come with the linux compiler as > they probably wouldn't play nice. I don't recall exactly how crt0 gets loaded in linux nor in CapROS; this would need to be figured out. DOMCRT0 in src/build/make/makevars.mk is no longer used, but was once used to explicitly load crt0, and we could go back to that. > 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. src/base/domain/openssl is one of those "alien" things, and instead of using configure, the Makefile explicitly builds for the CapROS targets. >> 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
