Re: Questions regarding armhf port for Raspberry Pi

[Mike Thompson <mpthompson@gmail.com>]

Thank you for the response.

On Tue, Apr 3, 2012 at 3:17 PM, peter green <plugwash@p10link.net> wrote:

Note that you don't actualy have to use --foreign in this case since your host kernel can run the binaries for the target.

I used the --foreign option because as far as I can tell, the armhf binaries can only run after I do a chroot.  Obviously the kernel stay the same on each side of the chroot.  I do the first stage debootstrap on the armel side of things, chroot, and complete the deboostrap on the armhf side of things.  Perhaps debootstrap doesn't actually execute any of the armhf code -- I'll leave off the --foreign option off and see what happens.  It will make things a little easier if it works.
 

I'd say the next step would be to try and setup an autobuilding system to build the rest of the packages. Now you have the root filesystem built i'd suggest using a "build-up" approach (that is ONLY giving the autobuilder access to the packages you have built). You may also want to try and find a way to automate the check for armv7 code and run it before introducing new packages into your archive.

You will also need to sort out a system to import new changes from debian where you have not made source changes and notify you that merging is required where you have made source changes (hopefully only a handful of packages).

I'd suggest working with wheezy rather than sid since the churn rate will be lower there and it's probablly what your users will want in the end.

Except for one package, I'm pulling all the sources from wheezy. I ran into some build issues and looking up the problem with google, using the sid package was the suggested fix.
 
I'm still in learning mode with the various package building tools for Debian, but I'm slowly getting a better understanding.  Automating the builds is very high on my todo list.  Unfortunately, I'm running into what I believe is a potentially serious compiler issue which has sidelined me for a few days while I investigate the error.

Any insight someone could provide into debootstrap/dpkg pre-dependency issues would be very helpful.

You are more likely to find someone who knows about debugging debootstrap issues on debian-dpkg but I wouldn't worry too much about it for now,

Yeah, if I run it a second time the resulting install seems fine.  I'll ignore it for now.

Among the packages I needed to build, I ran into two that failed because gcc 4.6.3 aborted due to an internal compile error -- perl and aptitude.  It seems to occur after RTL generation and optimizations when the compiler is trying to map RTL code to assembly code.  I built gcc 4.6.2 and it had the same issues and I was unable to build gcc 4.7.0 because that package is immature and won't yet build on ARM systems to to eglibc issues.  I guess I'll try the Linaro source for gcc, but it seems those patches have been sucked into Debian already so I'm not hopeful there.

This is an issue specific to gcc producing ARMv6+VFP code as the packages can be compiled under regular armhf fine.  I can create the packages by commenting out the code that offends the gcc compiler, but this creates a broken package and it worries me that gcc is not up to snuff for compiling all the other packages that need to come over.  It's probably worthwhile for me to spend time now to understand and hopefully fix this issue, otherwise I'm sure it will haunt me down the line.

I filed a gcc bug report at the following URL with a repeatable test case if someone was interested in helping me fix it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52855

An ARMv6 compiler issue is the last thing I wanted to be chasing down right now, but it is what it is.

Mike