I changed several things today (compiler, configs, etc. ) before I was able to test, and discovered a utility that must be run against zImages for RPi. In any case, dynamically linked executables are now working, even if I'm not 100% sure which change fixed it... That always bothers me, but I'll take it.
I have an official toolchain in a binary-only RPM now, though it wants to be installed with --no-deps, because it seems to think there are dependencies when there are none. So advice on building the RPM would be welcome. The majority of the remainder of my to-do list centers around building a disk image from the build artifacts, and getting a volunteer to review and test the changes :) Sent from my iPhone On Sep 18, 2012, at 2:46 AM, "Stuart Hughes" <[email protected]> wrote: > Hi Sean, > > Make sure the shared libraries etc are copied from the toolchain onto the > target in the right place (/lib and /usr/lib). Also check that > /usr/lib/libc.so (which is a text file) looks plausible {e.g GROUP ( > libc.so.6 libc_nonshared.a ) }. > > Regards, Stuart > > On 17/09/12 17:46, Malloy, Sean C. wrote: >> 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
