Action Item #492

Perform core build updates

Added by Hammel over 1 year ago. Updated over 1 year ago.

Status:ClosedStart date:26 Jan 2016
Priority:NormalDue date:
Assignee:Hammel% Done:


Target version:001 - Proof of concept
Severity:03 - Medium


It's time to do core build updates. This includes the following:
  1. Crosstool-NG
  2. Buildroot
  3. Linux kernel from RPi repo

This needs to be test built on Fedora and CentOS.


#1 Updated by Hammel over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

I rev'd to the latest Crosstool-NG and that built fine on CentOS 6.7. I then built the latest stable kernel from the upstream Raspberry Pi kernel repo, which is 4.1.y. That built fine too.

Then I tried to rev to the latest Buildroot. That's a bit more work. Instead of wasting time on that port, which I can do later, I'm just making sure that the current version in use - 2015.02 - still builds. I've already found that I needed to patch the pcre build. That may be the only problem unless some other projects have dropped support for the currently selected version. The build is till running, though.

#2 Updated by Hammel over 1 year ago

  • % Done changed from 20 to 50

I've got all the updates in place to move to the latest Crosstool-NG, and kernel 4.1.y from Raspberry Pi kernel repo. I've patched the 2015.02 Buildroot build and some of my core packages (libpibox and pnc) so it builds properly on CentOS 6.7. I expect it will also work on Fedora. Everything built okay but I forgot to rev the kernel in the configs (I had tested by specifying the kernel on the make command line) so I'm rerunning the build one more time before I check in the updates.

After that I'll do a test build on Fedora 22. Once that builds cleanly I'll test the build on hardware. If that works, then this will become the default build and I'll check it all in.

I also have mods to the mksd and mkinstall scripts to generate an image file that will be checked in around the same time.

#3 Updated by Hammel over 1 year ago

After attempting an update I ran into some problems getting the latest 4.1.y kernel tree to work on hardware. So instead of bumping ahead there I decided just to make sure buildroot was up to date and that I was using the latest toolchain I could manage. Then keep the working kernel version (3.14.y).

I'm now building with 3.12.x headers for the toolchain against a 3.14.y kernel from the upstream kernel repo for Raspberry Pi. Buildroot is also updated to know that the toolchain is at 3.12.x. That should get me working again. Then the majority of changes will come in buildroot, where lots of packages have changed. I'm sticking with the 2015.02 release for now. The next round of core updates will look at migrating to 2015.11 or later and a later kernel.

#4 Updated by Hammel over 1 year ago

  • % Done changed from 50 to 60

I got a full build to complete on both CentOS 6.7 and Fedora 22. However, the binary built on Fedora 22 crashes as soon as I try to run pibox-network-config. The most likely cause of this is the changes I made to the toolchain, specifically the gcc compiler.

So I decided to go back to the old toolchain but built with the newer Crosstool-NG (1.22), but that doesn't support the exact gcc (4.7.3) I had used previously. So I tried the next closest one, 4.7.4. Unfortunately, Fedora 22 has gcc 5.x and that won't compile gcc older than 4.8 (re: 4.7.x and earlier) due to some bug. I lost the output I had and the link that told me this was the case, but I know it's a fact (that lost link had a patch for it). So I bumped up to gcc 4.8.5. That built and is now being used to rebuild the rest of the distribution, which I'll try as soon as the build completes.

If this does the same thing I'll revert to xcc 1.19.0 and try again.

#5 Updated by Hammel over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100

Verified build is working on Fedora 22. Also verified that this build, with the 4.8.5 version of gcc, does not crash when I start pibox-network-config.

More testing is necessary but I'm fairly confident this will be a working configuration for a while to come. At least the toolchain is.

Closing issue. Will open new issues against the new build as necessary.

Also available in: Atom PDF