[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Rob Landley]

On 10/07/2013 07:17:08 AM, Kirk Terrell wrote:
> On 10/04/2013 08:09 AM, Andrew Bradford wrote:

>>> What niche is the CLFS embedded targeting - a raspPI can run a full
>>> blown desktop distribution?

What niche is LFS itself targeting given that Slackware still exists  
and predates it?

>> Determining what niche is hard but is a good question.  I think  
>> CLFS's
>> embedded book should show how to build a busybox (or similar) based
>> rootfs without needing to boot or chroot (like the main CLFS book).

Attempting to cross compile the whole of BLFS may not end well.


>> A better question, though, given that openembedded seems like the
>> predominant build system for doing this activity, would be should  
>> CLFS
>> embedded stop trying to show how to do a build like this by hand but
>> instead focus on teaching people how to use openembedded?

No.

>>  My first
>> impressions, both a few years ago when I looked at it and then again
>> recently, of openembedded or other bitbake build systems is that it's
>> very powerful but horribly documented on the how, why, and what  
>> happens
>> or how to expand it.

It's not just the documentation, it's the design. Board files and  
package files are not cleanly separated. I wanted to tell it "give me a  
basic build environment for these five boards" and "natively build this  
set of packages on whatever board you're running on", and it just  
doesn't think like that.

>> The learning curve for how to leverage oe/bitbake
>> effectively beyond just using Angstrom or similar is steep but it
>> doesn't need to be.
>> 
>> For instance, are there bitbake receipes/layers for making a
>> musl/busybox rootfs?  Would that be valuable?  Would a well written
>> documenation saying wtf is going on within the build process be  
>> useful?
>> 
>> Or am I off on a tangent?

Are you going to do the same for buildroot?

>> I'm kind of getting burned out with CLFS embedded lately.  There's a  
>> lot
>> that needs to be updated and I've been getting frustrated a lot  
>> lately
>> by that.  There was a good year or so break in my contributions to  
>> CLFS
>> embedded and not much happened during that time.  The developer  
>> interest
>> in keeping the book up to date seems to be very low.

I did a build system that creates cross compilers, uses them to build  
the simplest build environment capable of rebuilding itself under  
itself, and then boots under qemu to build more packages natively there.

I got the "simplest build environment" down to seven packages (and hope  
someday to get it down to four) but the toolchain I'm using is very  
stale at this point (the last GPLv2 release of gcc/binutils) and LLVM  
is still cooking.

Linux From Scratch has never been a directly deployable system because  
it has no apps. Instead it provides a build environment within which  
you can install arbitrary additional packages via "configure;make;make  
install". (And blfs documents the dependencies for doing so for lots of  
common packages.)

Presumably, the point of cross linux from scratch is getting that build  
environment up and running on an arbitrary target. You can always trim  
the deployed system later by deleting files or populating a new chroot.


> I'm not sure if an openembedded tutorial is a CLFS project - but if  
> you managed
> it your praises would be sung far and wide.

I want to get openembedded to build its packages and install them into  
the current filesystem (or a new chroot). Build them with whatever  
toolchain is in the host path for whatever architecture we happen to be  
running.

It's really not set up to do that.

> I skimmed thru an article in Linux Journal this month that was a  
> tutorial on how to put the debian distribution on a different ARM  
> board. Another option might be to focus on how to marry an existing  
> distribution with a board to get it up and running.

I'm very much interested in doing this for my aboriginal linux project.  
I already have automated build control images that let you boot qemu  
with a bundle of source code and shell scripts that automatically build  
stuff instead of just giving you a shell prompt, and I've decided that  
package management is beyond the scope of my project and what I really  
need to do is bootstrap an existing distro in a linux from scratch  
style environment.

Unfortunately, running the source version of debootstrap under LFS  
(without grabbing prebuilt binaries for an unknown architecture) turns  
out to be hard. Same for gentoo and fedora, plus variants like ubuntu,  
funtoo, and suse. Haven't tried slackware yet... Every distro assumes  
it's building under the previous version of _that_distro_, and is full  
of implicit assumptions about how the environment's set up and that the  
repository will be initialized by extracting a magic tarball from  
somewhere.

A project to bootstrap distros under Linux From Scratch without  
downloading a prebuilt binary chroot but actually doing so from source  
would be awesome. And hard.

Rob