PDA

View Full Version : Linux 64 bit - Please help test new toolchain



PaulStoffregen
01-04-2013, 03:43 PM
I've been working on building a more recent toolchain.

I could really use some help testing and feedback? Here's the code:

http://www.pjrc.com/teensy/beta/arm-none-eabi-linux64-test4jan12.tar.gz

To use this, just replace the copy in hardware/tools. This one is a true 64 bit build. It's gcc 4.7.2, instead of the old 4.4.1.

MichaelMeissner
01-05-2013, 04:49 AM
Unfortunately, the laptop that I'm using that is running Fedora 14 will not run the compiler, since Fedora 14 only has glibc 2.13, and the compiler you build requires glibc 2.14. Since, the graphics chip in the system is not fully supported in Fedora 15 and with the introduction of gnome3 (bleeh) has made it unlikely that I will upgrade the system in the near term.

PaulStoffregen
01-05-2013, 11:55 AM
I tried recompiling the toolchain on Ubuntu 10.04 (in a virtual machine). The GMP library compiled but 2 of the 59 tests failed.

I'll try again on Ubuntu 10.10 soon....

MichaelMeissner
01-05-2013, 02:32 PM
I tried recompiling the toolchain on Ubuntu 10.04 (in a virtual machine). The GMP library compiled but 2 of the 59 tests failed.

I'll try again on Ubuntu 10.10 soon....
Unfortunately building newer versions of GCC means you have to build the support libraries (particularly GMP, but also MPFR and MPC) as well. If you are going to distribute the compiler, you need to build only static versions of the support libraries. I have various perl scripts I've worked on over the years to do this. I can probably build you one on Fedora 14. Did you start with with the 4.7.2, or are there local patches.

PaulStoffregen
01-06-2013, 01:16 PM
Here's a copy built on an older version of Ubuntu.

http://www.pjrc.com/teensy/beta/arm-none-eabi-linux64-test6jan12.tar.gz

I ran into some strange problems related to building in a virtual machine. I built with Ubuntu 12.04 both native and virtual machine, and the virtualized one had issues the native build didn't. One was 2 failure on GMP's check. The other was involves a problem where virtualbox doesn't support symbolic links in shared directories. I tested this copy briefly and it seems to work, but I'm still investigating why the virtual machine build can't properly check GMP.

MichaelMeissner
01-07-2013, 05:20 AM
The compiler runs fine on my Fedora 14 system.

Just to be sure, when you make drops like this, you should make a tar/zip file of the sources you used to build it to comply with section 6 of the GPL. It is easiest if you do it when you make the release (section 6a), rather than waiting for somebody to request the sources and then have to deliver them (section 6b).

In terms of GMP failing in the virtual machine, the only thing I can think of is perhaps the virtual machine isn't configured to use the same instruction set (SSE, SSE2, etc.) as your host machine, and there is some subtle reliance on floating point precision in the test.

PaulStoffregen
01-07-2013, 09:42 AM
I was going to go with section 6b, until this was officially published on the website, where I plan to offer a source code link. But since you asked, I'm uploading the source now.

http://www.pjrc.com/teensy/beta/arm-none-eabi-linux64-test6jan12-src.tar.gz

It's never been my intention to withhold any GPL source code.

Other than a couple trivial patches and my own build script, it's just the source published by CodeSourcery. My build script and the 3 tiny patches I'm using are included, so if you want to build this, just run the script. My desktop machine builds the whole thing in 13 minutes.

MichaelMeissner
01-07-2013, 12:27 PM
It was never my intention to imply otherwise. I just figured it slipped through the cracks (plus if you hadn't been as fast, I was going to do a build myself with the back level build, and I just wanted to start with the same version).

I've seen cases where it comes back to bite people who are less organized than you are, and when they need to produce the source, they can't locate the particular version that went into a release. Part of it was just old habits in dealing with companies I was employed at in educating them on how to do their releases so it is right the first time, and get it ingrained in their build process.