Re: [Ltib] LTIB for Raspberry Pi

[Malloy, Sean C.]

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" <address@hidden> 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
>