I've been using the custom option to build with my home-grown toolchain, so
testing the official Pi toolchains shouldn't be a big deal. RPM-ize-ing the
officially released toolchains seems like the way to go. Links to crosstool-ng
with a sample config file for rpi should satisfy the teach-a-man-to-fish spirit
of online collaboration.
The shared library situation is puzzling. Like I said, a hand-built (outside
of LTIB), dynamically linked HelloWorld executable placed on the Pi produces
output, and will even run if init=/bin/hi is passed into the kernel.
But any LTIB-produced dynamically linked executables act like the shared libs
don't exist. Setting LD_LIBRARY_PATH, LD_RUN_PATH, etc. are of no use. I've
attempted to get ltrace (statically linked) to build for ARM, but have quickly
run into issues (the autoconf that LTIB uses when doing scbuild is too old for
ltrace's liking), and getting it to cross-compile without LTIB hasn't exactly
come for free.
So, my thoughts are that I'll rebuild from scratch using an official toolchain
and see what happens. I have to test a new toolchain anyway; might as well :)
Someone asked about the Pi's bootloader situation. My understanding is that the
GPU runs first when the board is powered up. It looks for an executable to
load& run on the first (VFAT) partition on the SD card, and that this
executable is closed-source, provided by the Pi foundation (and/or Broadcom), and
does traditional boot-loader-y things, like set up memory (which is shared between
the GPU and the ARM CPU, I believe), and load a kernel. I suppose there's no
reason we couldn't then run uBoot instead of a linux kernel, but there seems little
point. There is no ROM part, so the device must boot from the SD card.
In any case, I look forward making LTIB generate my very own SD card image file
:p