[Clfs-support] CLFS for ARM/OpenRD/Plugcomputer

[Lance Jump]

 On Sat, Jul 10, 2010 at 10:14 AM, Joe Ciccone <jciccone at gmail.com> wrote:
>  On 07/09/2010 02:32 PM, Lance Jump wrote:
============ SNIP ================
>>
>> I have made it past the gcc-final stage with the arm-sysroot by
>> disabling shared libraries. Almost everything built after that through
>> xzutils at the end of chapter 6.
>
> If I remember building gcc, binutils, and {e,}glibc for arm all had issues
> compiling for arm. I have some patches floating around, but nothing is
> finished yet.

If there is something you want me to try, let me know. This is for
fun, not work, so I can only do it in my spare time. Since it is all
scripted, I can get two builds in per day (overnight and while I'm at
work). Also, because it is a VM I could send you the machine or
snapshots if you wanted see or run anything.

>>
>> The automake build failed because the host autoconf was too early for
>> it (2.6.1) so I installed 2.6.3 as a host tool and then automake
>> built.
>>
>> Perl failed to build and I am still trying to track that down. It's
>> first complaint was that it could not find miniperl-cross and it went
>> downhill from there with missing Makefiles and Config.pm's. It looks
>> like it could be some sort of search path problem since there is a
>> version of Perl on the host.
>
> This is expected, perl was not really designed to be cross-compiled without
> access to the host, and I do not believe I have a patch for the new version
> yet.

I have always thought of the build machine as my host. I really wanted
to create a chroot environment so I could run inside my build/host
being sure to use the only the tools built for it. The build machine
is the LFS live installation and the host is wherever I run the chroot
(which could be on the LFS live machine). This is the approach I took
about 2 years ago using LFS with great success. Can I do that here? If
so, at what point can I do it?  Will this help with the Perl build?

>>
>> I also just noticed that the gcc-specs patch, which is not called out
>> in the arm-sysroot book, contains dynamic loader path substitutions of
>> "/tools" But arm-sysroot does not appear to "/tools."  It uses
>> $CLFS/cross-tools. I don't know whether to include the patch or not. I
>> get the same failure with or without it. So my latest attempt is to
>> link /tools to ${CLFS}/cross-tools, use the patch and try again.  I'll
>> know in a few hours.
>
> This is by design, sysroot does not have a separate final system build. In
> the main book, when you build the final system you have to be booted into
> the target architecture, with sysroot, you could build the entire arm system
> on a x86_64 box. Unfortunately, sysroot still has a lot of bugs in it and as
> you can see from the date, it hasn't been updated in a while.

I don't fully understand sysroot, but it sounds "chroot-like" for
individual tools, but with a greater chance of inadvertently using
unwanted build-system (or host-system) files, especially for tools
that don't accommodate sysroot.

>>
>> I have not given up on your suggestion to port 1.1.0 -- I just have to
>> steel myself for that task. If you know of anyone who has done it or
>> is doing it, let me know.
>
> I believe your best bet is to start with the sysroot arm or embedded arm
> book. Right now, it is going to be a lot of work to get a build going for
> arm, but it is doable. I have a beagleboard that I try to regularly do
> builds for.

I am building on a 32 bit x86 platform (a LFS lived installation on a
virtual machine).  I would like it to create a chroot environment in
which to do my builds so I can lock down the tools without impacting
the host. I have no real desire to run native compilers on the target
right now. Does this suggest embedded rather than sysroot?

Note that my goal is less building the cross toolchain/build
environment than it is creating the target run-time system from source
packages of my choosing. While I would like to build the toolchain
from scratch as well, I am willing to skip that step for now and use
an exiting toolchain.

I found that, after some false starts, I was able to build an arm
toolchain with crosstool-ng, although I have not tried to build
anything with it. My original mission in doing this was to see if it
worked and then study the process to gain insight into the CLFS issues
I was having. It was a little too automated and monolithic to gain
much understanding, other than it could be done. But perhaps I could
use the toolchain as a starting point and then follow along with CLFS
for building the run-time system. I don't quite see the clear dividing
line the between the two, but I'm sure I could figure it out.

> I don't know when I'll have time to get the book updated, but if someone has
> the time to do it, update the book and make a patch and I'll gladly apply
> it.

I am willing to help, but my time is constrained (as I am sure is
yours) and, more importantly, I may not have the requisite skills.
Still if there any way I can help, let me know. There appears to be a
lot of hard work and dedication behind LFS/CLFS and I'd like to
contribute however I can.