My message below was intended for the entire list, not just for Matthew. -Paul
---------- Forwarded message ---------- From: Paul Hargrove <phhargr...@lbl.gov> Date: Tue, Apr 28, 2015 at 4:20 PM Subject: Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms? To: Matthew Fortune <matthew.fort...@imgtec.com> On Tue, Apr 28, 2015 at 3:47 PM, Matthew Fortune <matthew.fort...@imgtec.com > wrote: > > 1) Is there any effort (current or planned for the near-future) to > revive any of the IA64, ARM, MIPS or SPARC systems? > > > > MIPS boards in the form of some edge router pros are currently being > shipped to the CFarm in France courtesy of Imagination Technologies. > That is good news. Thanks. > Ø 2) Is there any desire from users to see QEMU-emulated ARM, MIPS or > SPARC within cfarm if the real h/w is non-recoverable? > > > > For non-performance testing I am keen to make as much use of qemu as > possible in test environments. That includes all of bare metal testing > using qemu system emulator, Linux tools via the user-mode emulator. I > haven't ever looked at the performance of building GCC inside a QEMU > emulated full system emulator with Linux but I suspect it may be > prohibitively slow. > FWIW: There is a "neat trick" one can use involving distcc. Basically you run configure and make in the full-system emulated environment, but the "build" gcc is "distcc" which will ssh to a cross-compiler running on another host (or more than one). All pre-process and link steps remain in the emulated environment, so only a cross-compiler and cross-assembler are needed - no sysroot filled with headers is libs are required. The gcc-4.9-[tuple] and binutils-[tuple] packages from emdebian.org work well for this on an x86-64 host. While I've not tried building gcc this way (but might try now with --disable-bootstrap) I've found this far faster than compiling inside the emulator, and yet easier to maintain than a classic cross-compile environment[1]. There is the added bonus that this "just works" for software that has no cross-compilation support in its build infrastructure, and for things like "make check" that don't "cross" (except with careful use of QEMU user-mode emulation). NOTE: This idea is not originally mine. You can find several online HowTos on this subject. -Paul [1] Emdebian is missing a working mips cross-gcc for x86-64, though cross-binutils are available. So, I had to build my own mips-linux-gnu-gcc but didn't need to worry at all about the stuff that normally populates the sysroot. > > > Thanks, > > Matthew > > > > *From:* Gcc-cfarm-users [mailto:gcc-cfarm-users-boun...@gna.org] *On > Behalf Of *Paul Hargrove > *Sent:* 28 April 2015 23:32 > *To:* gcc-cfarm-users@gna.org > *Subject:* [Gcc-cfarm-users] Future of non-x86/Linux platforms? > > > > I've seen this topic addressed in the archives, and don't want to restart > any of the arguments about how useful/relevant CFarm has become. > > From my point of view "beggars can't be choosers" and so this email is > just my observations and a few questions and NOT any sort of complaint. > > > > As others have observed, the gcc-cfarm systems that are currently usable > are almost exclusively x86-64/Linux. > > There are certainly notable exceptions, such as > > + The POWER7 and POWER8 systems donated by IBM (thanks guys!). > > + AIX and NetBSD on gcc111 and gcc70, respectively > > + The VMs on gcc76 > > > > Since most of us probably use Linux or OSX on x86-64 every day, this is > not "diverse" for some of us (though I know our definitions of "diverse" > will differ). > > So, I want to ask: > > > > 1) Is there any effort (current or planned for the near-future) to revive > any of the IA64, ARM, MIPS or SPARC systems? > > > > 2) Is there any desire from users to see QEMU-emulated ARM, MIPS or SPARC > within cfarm if the real h/w is non-recoverable? > > > > 3) Is there any desire from the users to see newer {Free,Net,Open}BSD than > presently in gcc76's set of VMs? > > > > 4) Is there any desire from the users to see Solaris on x86-64 (either VM > or bare metal)? > > > > Before somebody jumps on me: > > > > I am *not* trying to push more work on the CFarm admin(s). > > In fact, if there is interest in #2 or #3, I may be able to help by > providing drive images I use on my own system now. > > If there is interest in #4, Oracle provides pre-packed installers for use > with VirtualBox. > > > > Of course, if my questions show ignorance of some resources already > available in the cfarm, please let me know. > > > > -Paul > > > > -- > > Paul H. Hargrove > > Computer Languages & Systems Software (CLaSS) Group > > Computer Science Department > > Lawrence Berkeley National Laboratory > -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
_______________________________________________ Gcc-cfarm-users mailing list Gcc-cfarm-users@gna.org https://mail.gna.org/listinfo/gcc-cfarm-users
