PiBox

1.15.2 builds on Fedora 16 and CentOS 6.2/6.4. It does not build on Fedora 19. The problem with the latter is that PPL fails with this error:

[ERROR]    configure: error: Cannot find GMP version 4.1.3 or higher.

However, GMP 5.0.2 is built by Crosstool-NG right before PPL is built, so for some reason on F19 PPL doesn't see the just built GMP. What's worse, Fedora 19 comes with 5.1.1. If I installed the gmp-devel package the build gets past the missing GMP version but still fails in PPL due to some header incompatibilities.

So it looks like the PPL build in 1.15.2 is relying on the build hosts GMP installation and PPL 0.11.2 is not compatible with GMP 5.1.1. I'll have to try 1.15.3 or later.

• 1.15.3
• 1.16.0
• 1.17.0
• 1.18.0
  on Fedora 19. All failed with messages similar to:

[ERROR]    /home/mjhammel/src/ximba/raspberrypi/src/../bld/crosstool-ng-1.18.0.bld/work/src/ppl-0.11.2/src/mp_std_bits.defs.hh:109:7: error: redefinition of 'class std::numeric_limits<__gmp_expr<__mpq_struct [1], __mpq_struct [1]> >'
[ERROR]    /usr/include/gmpxx.h:3306:21: error: previous definition of 'class std::numeric_limits<__gmp_expr<__mpq_struct [1], __mpq_struct [1]> >'

It looks like gmp 5.1.1 on the build host is not compatible with PPL 0.11.2, which is the most recent version available through Crosstools-NG.

Seems to me the bug is that Crosstool-NG builds ppl without specifying the just-built GMP as an override to the build host's GMP.

Rebuilt everything with the 1.19.0 toolchain but I get the same problem as with the 1.18.0 - "no init found".

• The kernel boots fine and the rootfs is mounted as ext3 by the kernel.
• The cmdline.txt does not contain an init= entry.
• Busybox is there an symlinked to /sbin/init.
  

  $ file bin/busybox
  bin/busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.3, stripped
  $ ls -l sbin/init
  lrwxrwxrwx 1 root root 14 Mar  2 22:09 sbin/init -> ../bin/busybox
  

So I'm not sure what is broken with this toolchain. But I can be sure that its the way the toolchain is built that causes the problem since the kernel and rootfs (and cmdline.txt) all work with 1.15.2.

One other thing: the 1.15.2 build does have support for 4.7 gcc, both GNU and Linaro versions. I can try those to get around this issue. But it would be nicer to get the latest Crosstool-NG working.

1.19.0 was configured to use kernel 3.10.2. I changed this back to 3.2.48, which is the version of the 3.2.x branch supported by 1.19.0.

Rebuilding xcc, after which I'll rebuild everything else and try again.

I built a minimal, statically linked Busybox using the 1.19.0 toolchain and it booted. This tells me there is something wrong with how the Buildroot rootfs is put together. I'm thinking it has something to do with where it finds ld.so or libc or something.

I may be able to verify this by looking at the package/customize/source directory, which is where I place the sysroot files. However, I rev'ed everything (OS, gcc, libc, etc.) in 1.19.0 and started to build everything again. So I have not buildroot tree to examine right now. I'll check it again after I do the full build.

This next build will be tested with the minimal Busybox first. Then I'll review the Buildroot build.

1.19.0 with latest compiler/libc/OS configurations worked with a statically built Busybox. So it's back to "why doesn't the kernel see the rootfs"?

I looked at 1.19.0's sysroot and compared it to the Buildroot target build on a different machine. I noticed in the later there is this symlink under /lib:

$ ls -l ld*
-rwxr-xr-x 1 mjhammel mjhammel 162248 Feb  1 16:56 ld-2.13.so
lrwxrwxrwx 1 mjhammel mjhammel     10 Feb  1 16:56 ld-linux.so.3 -> ld-2.13.so

But under 1.19.0's sysroot it looks like this:

$ l -l ld*
-rwxr-xr-x 1 mjhammel mjhammel 172016 Mar  6 21:07 ld-2.17.so
lrwxrwxrwx 1 mjhammel mjhammel     10 Mar  6 21:07 ld-linux-armhf.so.3 -> ld-2.17.so

So I'm wondering if the missing ld-linux.so.3 symlink is the problem. I found a discussion on using ld-linux.so.2 so I ran the following on the busybox binary in the Buildroot for a 1.15.2-based rootfs:

$ readelf -l busybox 

Elf file type is EXEC (Executable file)
Entry point 0x11ae8
There are 8 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x0ad834 0x000b5834 0x000b5834 0x000c0 0x000c0 R   0x4
  PHDR           0x000034 0x00008034 0x00008034 0x00100 0x00100 R E 0x4
  INTERP         0x000134 0x00008134 0x00008134 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.3]

There was other stuff printed, but the important part is the reference to the program interpreter. That's the symlink in the working Buildroot. Interestingly I've hit this before because there is a comment in xcc.mk about a missing ld-linux.so but there is no code for generating that link.

What I want to do is run readelf on the busybox binary for the 1.19.0 build and see what that says. If it points to a non-existant program interpreter then I think I have my culprit.

I will build Buildroot and test it as is, expecting it to fail. As soon as Busybox is built I'll pass it through readelf to check that. Assuming the link is missing, I'll manually add that symlink to the SD card and see what happens. If that works, then the xcc build has to be adjusted for 1.19.0 without breaking 1.15.2.

So this sucks:

$ readelf -l bin/busybox

Elf file type is EXEC (Executable file)
Entry point 0x12128
There are 8 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x0ab9f8 0x000b39f8 0x000b39f8 0x00008 0x00008 R   0x4
  PHDR           0x000034 0x00008034 0x00008034 0x00100 0x00100 R E 0x4
  INTERP         0x000134 0x00008134 0x00008134 0x00019 0x00019 R   0x1
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]

Which means that busybox is referencing the correct symlink. So if this build doesn't boot then I have some other problem. Ugh. Unless, after performing the sysroot install into the target rootfs the symlink disappears. Will have to check that when the build completes (it's still running). I don't think that's the issue since the customize tree is created at the start of the Buildroot build (and that copies sysroot plus other stuff into a package directory in Buildroot before running the build) and that tree has a valid symlink. Plus the copy from there to the target is done with a post-build script that uses the same copy mechanism (rsync). So I'm guessing the symlink will be there.

Will have to wait and see if it boots or not.