[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
___
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users
Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?
On Tue, Apr 28, 2015 at 4:24 PM, Vincent Lefevre wrote:
> On 2015-04-28 15:31:50 -0700, Paul Hargrove wrote:
[...snip...]
>
> > 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?
>
> If (1) is not possible, I think that the only possibility is to use
> emulated VM's. Now, I suppose that most users should be able to do
> that on their own machines (once they find some good tutorial so that
> they won't have to spend hours reading documentation).
>
> > 3) Is there any desire from the users to see newer {Free,Net,Open}BSD
> than
> > presently in gcc76's set of VMs?
>
> Having access to both old and new versions would be useful.
>
[...snip...]
If the argument that "most users should be able to do that" is sufficient
to prevent deployment within cfarm, then I doubt any of the VMs on gcc76
would be needed.
In fact, deploying a virtual a x86-64 system running one of the BSDs or
Linux versions hosted on gcc76 is marginally easier (and significantly
faster) than doing the same with a QEMU-based emulator.
If there is sufficient interest, I can consider looking for the time to
de-personalizing the disk images I have and share them with the gcc-cfarm
community.
I have images for three ARM systems (gnueabi/ARMv5, gnueabihf/ARMv7 and
aarch64/ARMv8) and two MIPS systems (Malta with 4Kc and 5Kc cpus), all of
which are running either Debian Jessie or Ubuntu Utpoic.
These really are not that hard to construct from the respective net-install
images once you have the right QEMU command line.
I also have images for FreeBSD-11, NetBSD-6 and OpenBSD-5 (all at or near
latest releases) for x86-64, which run under KVM (virtio disk and network).
These are more or less trivial to setup if you've ever provisioned a
KVM-based virtual machine before.
-Paul
--
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
Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?
On Tue, Apr 28, 2015 at 6:14 PM, Fotis Georgatos wrote (in part): > For the record, both hardware and virtual/simulated resources are useful, > for different purposes each. I agree entirely and that is exactly the spirit in which I was operating when introduced the question. I never intended to suggest that emulated systems were a perfect/complete replacement for the failed hardware. My question was intended to determine whether cfarm users believe (each according to their own needs) that there was enough value to some sort of shared/central effort to deploy/access/maintain some emulators, and predicated (perhaps incorrectly) on the expectation that the answer would be "no" if real hardware was restored to cfarm. -Paul -- 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
[Gcc-cfarm-users] Fwd: Future of non-x86/Linux platforms?
My message below was intended for the entire list, not just for Matthew.
-Paul
-- Forwarded message --
From: Paul Hargrove
Date: Tue, Apr 28, 2015 at 4:20 PM
Subject: Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?
To: Matthew Fortune
On Tue, Apr 28, 2015 at 3:47 PM, Matthew Fortune 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
>
> Co
Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?
On Tue, Apr 28, 2015 at 7:31 PM, Paul Hargrove wrote:
[...snip...]
> FWIW: There is a "neat trick" one can use involving distcc.
>
[...snip...]
> 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
>
[...snip...]
Some totally NON-scientific results for the curious.
Commands:
/usr/bin/time [...]/gcc-4.9.2/configure \
CC=arm-linux-gnueabihf-gcc-4.9 \
CXX=arm-linux-gnueabihf-g++-4.9 \
--disable-nls --disable-bootstrap --disable-multilib \
--disable-libsanitizer --disable-libcilkrts --disable-libitm \
--enable-languages=c,c++
/usr/bin/time make -j2 all-gcc
System 1: hardware
Raspberry Pi B+ running with 1GHz turbo-mode enabled.
This is a single-core cpu.
gcc tuple = armv6l-unknown-linux-gnueabihf
Running Raspbian (installed at Wheezy and updated to Jessie)
Elapsed configure time: 32 seconds
Elapsed make time: 3hr 42min
System 2: emulator + distcc (
QEMU-emulated guest: "qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 4"
Even though emulating a 4-core cpu, QEMU is single-threaded.
gcc tuple = armv7l-unknown-linux-gnueabihf
Guest is running Ubuntu Utopic
Guest $PATH setup so $CC and $CXX use distcc for ssh-based remote compile
(on a 2-core x86-64 KVM-guest on the same host)
Host: 32-core Opteron at 2.7GHz
Elapsed configure time: 2min 32sec
Elapsed make time: 2hr 14min
So the winner in this race: a split-decision
Because distcc runs configure tests (source file == "conftest.{c,cc}")
locally (meaning in the emulator), the real hardware beat the emulator on
the configure step by a factor of roughly 4.5.
On the "make -j2" step, however, the use of distcc resulted in a nearly
40% reduction in elapsed time.
Note that this set of commands is designed to avoid, as much I could, any
use of the built-compiler.
Results for a full build (with bootstrap and/or builds of the target libs),
would probably produce a different aggregate result because the in-emulator
execution of the just-built compiler will be horribly slow.
The point of the test, other than my curiosity, was to demonstrate that
applying this approach can be genuinely profitable (under
not-entirely-contrived circumstances).
-Paul
--
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
Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?
On Wed, Apr 29, 2015 at 5:32 AM, Jonathan Wakely
wrote:
> On 28 April 2015 at 23:31, Paul Hargrove wrote:
> > 3) Is there any desire from the users to see newer {Free,Net,Open}BSD
> than
> > presently in gcc76's set of VMs?
>
> I've found the BSDs are easy to run in a local VM, although it would
> certainly be nice if they were available on faster cfarm h/w.
>
> N.B. GCC also supports Dragonfly BSD now, and that runs well in a VM.
>
> I have root on gcc70 so could upgrade that to a newer NetBSD if the
> people using it would prefer a newer version. I might need simple
> instructions though, I find the pkg mgt stuff on NetBSD a real pain.
>
For a binary upgrade of NetBSD the recommendation is to boot from the
installation media.
That is going to be a pain if you lack physical access.
The installer's "upgrade" option installs a new instance of the base system
(a handful of tarballs) over the old system.
It does provide help preserving/merging your configuration files.
Instructions for updating are at
https://www.netbsd.org/docs/guide/en/chap-upgrading.html
That covers the base system which lives outside the pkg management -
updating your external packages would be an additional step, IIRC.
However, that should be just "sudo pkgin fug" (fug = full-upgrade), again
IIRC.
Note that at the very of the page I reference above is a short blurb about
"sysupgrade" as a live binary upgrade alternative.
It mentions it being "new", but that is from Aug 2012. I *have* used it
successfully, but your results may vary.
All of that said, I agree with Vincent Lefevre who said earlier in this
thread
"Having access to both old and new versions would be useful."
However, gcc76 does have VMs for both NetBSD 5.1.2 and 6.0 - so updating
gcc70 from 5.1 is not a "big loss" IMHO.
So, updating cfarm's only bare-metal NetBSD system (gcc70) gets a +1 from
me.
> 4) Is there any desire from the users to see Solaris on x86-64 (either VM
> or
> > bare metal)?
>
> Solaris and Darwin are the targets I most often wish I could test on.
>
[...snip...]
They are, unfortunately, the hardest to virtualize in my experience.
For my own Darwin testing I have a collection of used Mac Minis and laptops
covering each of the 10.x releases since 10.4.
> 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.
>
> Yeah, I couldn't get that to work on my Fedora machine and gave up.
>
I have VirtualBox on my Mac laptop and have seen no problems with
Solaris-11.2 within that.
Note that Solaris-11.x is known NOT work in QEMU or KVM (tests with ping
show network can send but not recv).
As the owner of both projects/products, Oracle actually recommends (and
supports?) Solaris within VirtualBox.
Unfortunately KVM, Xen and VirtualBox are all mutually exclusive -
requiring you to dedicate a host to running VirtualBox.
-Paul
--
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
Re: [Gcc-cfarm-users] gcc113/114/115/116: four new 8 cores ARMv8-A 1.6GHz machines / 32G RAM / 500G disk
I am not sure a full-blown chroot is necessary, especially in light of the limited disk space on these systems. There is already a support request for the installation of the armhf/multilib compiler packages. Those bring in the necessary basic libs (libc, libstdc++, etc) as package dependencies. That should (based on my use of a similar setup within QEMU) be sufficient to compile and run ARMHF and THUMB executables. -Paul On Tue, Oct 20, 2015 at 9:52 AM, Ramana Radhakrishnan wrote: > On Sun, Oct 18, 2015 at 5:25 PM, Torbjörn Granlund wrote: > > Segher Boessenkool writes: > > > > On Sun, Oct 18, 2015 at 05:30:28PM +0200, Torbjörn Granlund wrote: > > > Laurent GUERBY writes: > > > > > > We're pleased to announce that four new servers running AArch64 8 > core > > > processors are now available in the GCC compile farm (1): gcc113 to > > > gcc116.fsffrance.org. The machines have been donated by ARM (2) > hosted > > > and configured by OSUOSL (3). > > > > > > Nice. > > > > > > Which processor core do these use? > > > > APM X-Gene "Potenza". > > > > > I tried to figure this out with some searches, but alas I came up > with > > > no information. > > > > xxd /proc/device-tree/cpus/cpu@000/compatible > > > > > Specifically, is it Cortex-A53, A57, or A72, or is it some > independently > > > developed core? > > > > > > It is clear the the CPUs run at 2.4 GHz and not 1.6 GHz as > > > https://gcc.gnu.org/wiki/CompileFarm claims. > > > > That isn't clear at all; what test did you use? > > > > A tight loop in assembly code. Aside from loop control, I use a > > dependent chain of plain instructions, and measure the delta as I change > > the count of dependent instructions. > > > > Modern pilelines are complex, so the counts might fluctuate bit. These > > didn't; 3 dependent instructions took 3 2.4 GHz cycles, 4 dependent > > instructions took 4 2.4 GHz cycles, etc. > > I remember being told these were 1.6GHz machines when we arranged for > these to be delivered - will double check. > > I plan to set up armhf chroots in the coming weeks (read spare time) > that developers can access using schroot on these machines as this > would give folks access to a fast machine for aarch32 development too. > Do people feel strongly against doing so ? > > > Thanks, > Ramana > > > > > > > > (To exclude zany "Turbo" modes, I loaded all 8 cores.) > > > > > > -- > > Torbjörn > > Please encrypt, key id 0xC8601622 > > > > ___ > > Gcc-cfarm-users mailing list > > Gcc-cfarm-users@gna.org > > https://mail.gna.org/listinfo/gcc-cfarm-users > > ___ > Gcc-cfarm-users mailing list > Gcc-cfarm-users@gna.org > https://mail.gna.org/listinfo/gcc-cfarm-users > -- 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
Re: [Gcc-cfarm-users] gcc113/114/115/116: four new 8 cores ARMv8-A 1.6GHz machines / 32G RAM / 500G disk
On Tue, Oct 20, 2015 at 12:31 PM, Ramana Radhakrishnan wrote: > > To be clear, personally I have access to a different aarch64 > > machine with a chroot setup, so I don't need this particular > > part of the compile farm. > > Likewise. While I have no aarch64 h/w, I do have armhf h/w. So, the details of chroot vs multilib for armhf development on the new systems is not of extreme importance to me. To paraphrase Peter: if Ramana is willing to do the work to set things up I will make use of it. -Paul -- 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
Re: [Gcc-cfarm-users] gcc113/114/115/116: four new 8 cores ARMv8-A 1.6GHz machines / 32G RAM / 500G disk
On Tue, Nov 24, 2015 at 9:43 AM, Pedro Alves wrote: > On 10/20/2015 06:03 PM, Paul Hargrove wrote: > > I am not sure a full-blown chroot is necessary, especially in light of > the limited disk space on these systems. > > There is already a support request for the installation of the > armhf/multilib compiler packages. > > Those bring in the necessary basic libs (libc, libstdc++, etc) as > package dependencies. > > That should (based on my use of a similar setup within QEMU) be > sufficient to compile and run ARMHF and THUMB executables. > > > > For GDB development at least, that's be sufficient and quite handy > to have. E.g., I just now wanted to try a Aarch64 gdb/gdbserver patch > related to debugging 32-bit/Aarch32 inferiors. > I tried to find the support request you mention, but failed to find it. > Was it resolved already? > Pedro, No, the toolchains for aarch32 have not yet been installed to the best of my knowledge. -Paul -- 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
Re: [Gcc-cfarm-users] Why do some machine redirect to other machines of different platforms and architectures?
Jeff, There actually two things you need to know about. 1. Some machines are only accessible via ports on other machines. This is described at https://gcc.gnu.org/wiki/CompileFarm#Machine_Detailed_List in a paragraph which begins "Machines without public IP...". In fact, gcc60 is used as the example: it is to be reached via port 9200 on either gcc12 or gcc13. So, that explains why DNS for gcc60 sends you to gcc12. 2. There are many machines listed that are dead or retired, and gcc60 is among them. You will find gcc60 on the "Offline" list https://gcc.gnu.org/wiki/CompileFarm#Offline So are all of the Sparc machines. -Paul On Sat, Jan 23, 2016 at 7:54 PM, Jeffrey Walton wrote: > Hi Everyone, > > Please forgive my ignorance > > I noticed a login to gcc60 (IA64) redirected to gcc12 (amd64). Similar > happened to me last week trying to get on a Sparc machine. The Compile > Farm wiki pages does not seem to have a discussion of it (or I missed > it, which is quite possible). > > Why are some of the hosts in the compile farm redirecting to different > machines? > > Thanks in advance, > > Jeff > > ___ > Gcc-cfarm-users mailing list > Gcc-cfarm-users@gna.org > https://mail.gna.org/listinfo/gcc-cfarm-users > -- 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
Re: [Gcc-cfarm-users] OT: MIPS and MIPS64 (was: Future of non-x86/Linux platforms)
Laurent, I was wondering if you have any estimate when the MIPS64 machines you mentioned will become available. We all appreciate very much what you do for our community. So, this is NOT intended to pressure you in any way. -Paul On Sat, Jan 2, 2016 at 1:21 AM, Laurent GUERBY wrote: > On Fri, 2016-01-01 at 22:58 +0100, Juan Francisco Cantero Hurtado wrote: > > On viernes, 1 de enero de 2016 13:39:09 (CET) Jeffrey Walton wrote: > > >> One thing that QEMU testing cannot do well is testing threaded > > >> applications and memory models. And with a fast enough processor, > > >> sometimes QEMU testing will be much slower. I have an example is > > >> running on a ThunderX (or even an Octeon 3 for those MIPS guys here > > >> > > >> :)). Doing a bootstrap/test will only take around 2 hours if you use > > >> > > >> all of the cores (48 of them). While doing a compiler build and > > >> test on a x86_64 using QEMU takes 4-5 hours instead. > > > > > >Sorry to wander off-topic > > > > > >I've been trying to source MIPS and MIPS64 in the US, but I've had a > > >lot of trouble finding them. They appear to be more popular in India > > >and China. I thought I tracked down a MIPS dev board, but the store > > >did not carry it. > > > > > >Can you make any recommendations for a MIPS or MIPS64 test board > > >that's reasonably priced? > > > > I'm listing only the cheapest ones: > > > > MIPS32: > > - MIPS Creator CI20 (IIRC, compatible with Debian) > > - Ubiquiti EdgeRouter X > > > > MIPS64: > > - Ubiquiti EdgeRouter LITE (compatible with OpenBSD http:// > > www.openbsd.org/octeon.html ) > > > > > > > >It would be nice if it could run, say, Debian 8 or Fedora and a > > >Buildbot slave for daily testing. > > > > > > Hi, > > New farm machines with MIPS64 will be announced in the coming days > (I'm very very late on this project ...) > > Happy new year, > > Laurent > > > ___ > Gcc-cfarm-users mailing list > Gcc-cfarm-users@gna.org > https://mail.gna.org/listinfo/gcc-cfarm-users > -- 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
Re: [Gcc-cfarm-users] gcc22/23/24: three new mips64r2 Cavium Octeon II V0.1 machines ERPro-8
On Wed, Apr 13, 2016 at 6:03 AM, Laurent GUERBY wrote: > Thanks to Imagination Technologies Limited for providing > the machines and technical support, > And many thanks to Laurent, Petar and the other beta testers. As small/slow as these machine might be relative to other CFarm systems, they are far superior to use of QEMU for MIPS testing. -Paul -- 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
Re: [Gcc-cfarm-users] gcc22/23/24: three new mips64r2 Cavium Octeon II V0.1 machines ERPro-8
Rich, The *default* ABI is "32", but (at least) "-mabi=64" and "-mabi=m32" are available (have not tried "-mabi=o64"). -Paul On Wed, Apr 20, 2016 at 5:09 PM, Rich Felker wrote: > On Wed, Apr 13, 2016 at 03:03:04PM +0200, Laurent GUERBY wrote: > > Hi, > > > > We're pleased to announce that three ERPro-8 machines donated by > > Imagination Technologies Limited (1) running dual core mips64r2 Cavium > > Octeon II V0.1 with 2 GB of RAM are now available in the the GCC compile > > farm (2): gcc22.fsffrance.org, gcc23.fsffrance.org and > > gcc24.fsffrance.org with both IPv4 and IPv6. > > > > The ERPro-8 is originally a Linux-based network router (4), but has been > > reconfigured to allow development and test in a Debian environment. > > > > Hosting is provided by the not for profit ISP tetaneutral.net (3) in > > Toulouse France. > > > > /home is NFS mounted from gcc45.fsffrance.org:/home > > > > The disks are not backuped and not RAID. > > > > "ssh my_user_lo...@gcc24.fsffrance.org" should work for all farm > > accounts. > > > > Operating system are currently configured as follows: > > * gcc22 - kernel 3.14.10 (EB), Debian 7.10 (Wheezy), gcc 4.6.3 > > * gcc23 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2 > > * gcc24 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2 > > (EB = big endian, EL = little endian) > > > > Be careful as these are very small and slow machines relative > > to other farm machines so always check if another user is running > > something and avoid test servers and cron jobs. > > > > As usual please use the GNA tracking system in preference to the mailing > > list, use "Support" requests: > > > > https://gna.org/projects/gcc-cfarm/ > > > > Thanks to Imagination Technologies Limited for providing > > the machines and technical support, > > Are these systems actually setup for 64-bit? gcc -dumpmachine on gcc22 > shows mips-linux-gnu, and seems to be targetting a 32-bit environment. > > Rich > > ___ > Gcc-cfarm-users mailing list > Gcc-cfarm-users@gna.org > https://mail.gna.org/listinfo/gcc-cfarm-users > -- 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
Re: [Gcc-cfarm-users] gcc22/23/24: three new mips64r2 Cavium Octeon II V0.1 machines ERPro-8
Carl, I cannot answer for why 32-bit is the default, but it is not so uncommon. Here is Debian Wheezy on PPC64: debian@wheezy:~$ uname -a Linux wheezy 3.2.0-4-powerpc64 #1 SMP Debian 3.2.68-1+deb7u1 ppc64 GNU/Linux debian@wheezy:~$ gcc hello.c debian@wheezy:~$ file a.out a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x7aa335bac96e4f56ae4cdf5a3823a359e3d90585, with unknown capability 0x4100 = 0x13676e75, with unknown capability 0x1 = 0xb0401, not stripped Debian Wheezy on SPARC64: phargrov@sparc64:~$ uname -a Linux sparc64 3.2.0-4-sparc64 #1 Debian 3.2.78-1 sparc64 GNU/Linux phargrov@sparc64:~$ gcc hello.c phargrov@sparc64:~$ file a.out a.out: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xcc3e4759e903d238cc9afe4ea5e9c5ebe6ab1b77, not stripped So, I am not surprised at all that the same is true for Debian on MIPS64. Same on Solaris for x86-64, FWIW. -Paul On Thu, Apr 21, 2016 at 2:45 AM, Carl Eugen Hoyos wrote: > Hi! > > On Wed, 20 Apr 2016, Paul Hargrove wrote: > > Rich, >> The *default* ABI is "32", but (at least) "-mabi=64" and "-mabi=m32" are >> available >> > > I also found out yesterday that -mabi=64 is needed but I wonder why 32bit > is the default: I would be very surprised if my compiler on Linux x86-64 > (that also supports x86-32) would not default to 64 bit. > > Carl Eugen > -- 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
Re: [Gcc-cfarm-users] How to connect to gcc42?
Unless I am mistaken, the mips64el hosts are gcc23 and gcc24.fsffrance.org It looks like gcc23 is up, but gcc24 has lost its NFS mount of /home (which prevents logins via ssh keys). -Paul On Thu, Jan 5, 2017 at 4:04 PM, Jeffrey Walton wrote: > Hi Everyone, > > I'm trying to perform some testing under mips64. It looks like gcc42 > provides mips64el and its online. > > $ ssh noloa...@gcc42.fsffrance.org > ssh: connect to host gcc42.fsffrance.org port 22: Network is unreachable > > I don't recall if we have to use a jumpbox for gcc42. > > Can someone point out what I am doing wrong? > > Thanks in advance. > > ___ > Gcc-cfarm-users mailing list > Gcc-cfarm-users@gna.org > https://mail.gna.org/listinfo/gcc-cfarm-users > -- 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
Re: [Gcc-cfarm-users] libmpc?
Steven,
On many/most cfarm machines there will be a stable build of gmp and
required other libs under /opt/cfarm
It appears that gcc13 is no exception.
I suspect, but have not verified, that adding the three directories
/opt/cfarm/{gmp,mpc,mpfr}-latest/lib to your LD_LIBRARY_PATH may resolve
your problem.
-Paul
On Fri, Jan 20, 2017 at 12:52 PM, Steven R Loomis
wrote:
> Hello, everyone
> on gcc13 I am having compile failures:
> /opt/cfarm/gcc-latest/bin/gcc --version
> gcc (GCC) 6.3.0
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> But when autoconf tries to run it:
>
> configure:2979: checking whether the C compiler works
> configure:3001: gccconftest.c >&5
> /home/iulius/autobuild/bin/gcc-6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/cc1:
> error while loading shared libraries: libmpc.so.3: cannot open shared
> object file: No such file or directory
>
> $ ldd /home/iulius/autobuild/bin/gcc-6.3.0/libexec/gcc/x86_64-
> pc-linux-gnu/6.3.0/cc1
> linux-vdso.so.1 => (0x77ffc000)
> libmpc.so.3 => not found
> libmpfr.so.4 => not found
> libgmp.so.10 => not found
> libdl.so.2 => /lib/libdl.so.2 (0x77bde000)
> libm.so.6 => /lib/libm.so.6 (0x7795b000)
> libc.so.6 => /lib/libc.so.6 (0x77608000)
> /lib64/ld-linux-x86-64.so.2 (0x77de2000)
>
> Hunting around the above path, I found /home/iulius/autobuild/bin/
> mpc-1.0.3/lib/libmpc.so.3
>
> but, is there a cleaner way to set up my path? Am I doing something else
> wrong?
>
> Thanks,
> Steven
>
>
>
>
>
>
>
> ___
> Gcc-cfarm-users mailing list
> Gcc-cfarm-users@gna.org
> https://mail.gna.org/listinfo/gcc-cfarm-users
>
>
--
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
