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 _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
