Re: Questions regarding armhf port for Raspberry Pi

[Mike Thompson <mpthompson@gmail.com>]

This is a follow up to my questions about creating an Raspberry Pi flavored armhf port.  Please let me know if I'm just causing noise here and my questions should be directed to another mailing list.

Where I'm at now is that I have several hundred armhf packages rebuilt and verified to be clean of ARMv7 code -- meaning they are using the hard float ABI and are compiled for hard float instructions, but should run on the ARMv6+VFP CPU on the Raspberry Pi.  The packages I'm building were chosen by examining which packages are installed after using debootstrap and build-essential on a standard armhf system, then rebuilding those packages with a gcc modified to output RPi friendly hard float binaries.  After each package was built I used scripts I created to verify the binaries are clean of ARMv7 code.  In cases where ARMv7 code leaked through I had to find the dependent packages that were being linked against and re-build those as well.

Using the packages above and creating a local mini-repository I'm now able to use debootstrap, along with some coaxing, to create a minimal Debian filesystem based on my rebuilt packages.  The first-stage debootstrap (--foreign) is done under Debian armel and then with chroot I then run the second-stage debootstrap.  As the Raspberry Pi hardware is not shipping yet, I'm using QEMU configured with an emulated ARMv6+VFP CPU and running standard Debian armel to perform the installation of the packages.

However, as mentioned above, debootstrap needs some coaxing.  During the second-stage run of debootstrap, I'm getting dpkg errors that abort the bootstrap process.  I can re-run debootstrap again and it will complete, but I would really like to understand why second-stage debootstrap can't complete the first time and fix the issues.  Also, looking in the debootstrap.log file I see a number of dependency warnings, but I'm not sure if these are just normal warnings which are a side effect of how debootsrap calls dpkg to install packages on a clean filesystem.

The specific error I'm running into is the following:

dpkg: regarding .../apt_0.8.15.10_armhf.deb containing apt, pre-dependency problem:
 apt pre-depends on libstdc++6 (>= 4.6)
  libstdc++6 is unpacked, but has never been configured.
dpkg: error processing /var/cache/apt/archives/apt_0.8.15.10_armhf.deb (--unpack):
 pre-dependency problem - not installing apt

For some reason, debootstrap (or perhaps it is actually dpkg) can't properly figure out that the libstdc++6 package must be configured before it attempts to install apt.  This is the only error of this kind and I can't tell what might be different about how apt package uses libstdc++ as a pre-depend.  Other packages don't fail in this manner.

I've googled this error, but I haven't found specific information on how to understand what's happening and fix the issue. I mostly find bug reports that simply indicate the issue is not that uncommon.

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

Thanks,

Mike Thompson