[Aboriginal] Why more/chroot-splice.sh doesn't work anymore.

[Rob Landley]

On 06/20/2011 04:36 AM, David Seikel wrote:
> I've got to the stage where I'm actually writing the app that is the
> device I'm being paid to develop, now that I have enough OS to actually
> support running it on real hardware.  One of the reasons I chose EFL as
> the graphic framework is that it's happy running on framebuffer or X.
> So now I can develop the app in my comfortable X environment, and test
> it every now and then on the real hardware and it's frame buffer.
> 
> Which means I now have two development streams, and I can switch
> between them as needed, more or less independently.  Polish the OS,
> and write the app.
> 
> For the polish the OS part, I'm thinking about how to split things into
> "stuff needed at run time to support the app", and "stuff needed at
> compile time to compile everything".  Which brings me on topic.

I _really_ need to do a blfs-bootstrap with the beyond linux from
scratch bits about X11, but it might have to run on top of the output of
the linux from scratch build.  Dunno what the prerequisites are...

I'm playing with the uClibc 0.9.31.1 release to see if fixing the stdio
locking made the various non-x86 targets less strangely flaky.  (Fingers
crossed, being able to reliably build LFS on several different hardware
targets would be WONDERFUL)...

> On Sun, 19 Jun 2011 13:20:25 -0500 Rob Landley <rob at landley.net> wrote:
> 
>> So I'm poking at lfs-bootstrap this weekend, and my design assumptions
>> seem to have crossed paths and cancelled each other out at some point.
> 
> Cool.  I'm yet to update to the latest Aboriginal version, but I should
> this week.
> 
> I have been thinking about those tags you have in the package list, and
> what to do about them.  The "# busybox" tags seem to be more useful as
> a comment about why some LFS package was not built, it's functionality
> being provided by busybox.

They're there so you can filter those out from your build, yes. :)

Haven't tested it to see what other package builds break yet.  I know a
couple INSIST on gawk being there but you can make a gawk wrapper script
that calls busybox awk and then they're fine.  (Lazy build systems...)

> The "# development" tag is much more interesting.  These are things
> that could be built into some mountable directory somewhere, such that
> it can be unplugged, leaving just the built system and an empty mount
> point.

Worth a try, certainly...

> Problem number one is just basic - where should this mount point
> be?  /usr/devel strikes me as a good choice for reasons I wont go into
> unless someone thinks otherwise.

No strong opinion.  That works.

> Next is that while the includes from all the other packages should
> likely go into /usr/devel, libs may or may not.  Compile time libs and
> libs used statically yes, dynamic libs no.  Will the user compile
> everything only statically?  For my project, parts of EFL don't like
> being compiled static, so I'm compiling the app dynamically.

parts of _everything_ don't like being compiled statically.  I need to
write a FAQ entry on that, and possibly break it out into more generic
documentation.

I note that I wrote half of busybox.net's FAQ and a lot of stuff
(espcially near the end) is just general development documentation for
embedded stuff.  "So _that's_ what vfork() does" and all that...

> I think Rob mentioned something about how to actually drive it all.

Feedback on requirements is great.  Implementation I tend to mull over
at length and discard LOTS of ideas before I find something I'm happy
with, so I'm open to suggestions but since I discard 95% of my _own_
ideas here...

>> Which means I should look at the current uClibc release again to see
>> if signal handling sucks less under NPTL.  But lemme re-establish an
>> LFS native build baseline first.  And possibly update it to the
>> current LFS release...
> 
> I'm in two minds about that.  I'm using GRUB, and had to back up to the
> last LFS that still used "legacy" GRUB.  On the other hand, I have
> stripped out most of LFS, either using busybox, or just dumping stuff
> that is not relevant.  Those small parts of LFS I have left are the
> version from Aboriginal, and the GRUB I'm using seems happy about that.

Bootloaders (other than QEMU's -kernel option) are outside the scope of
this project. :)

Afraid you're on your own there.  I plead ignorance.

> Meh, lets see what happens with what you produce.
> 
>> P.S.  I used to post this kind of stuff to my blog, but I'm trying to
>> post it here now.  Lemme know if you have a preference where it should
>> go?  If I do post it here, the list traffic is mostly me blathering on
>> about technobabble details, but if I blog it the list traffic tends to
>> get really sparse and the comments I get about it are in private email
>> instead of here...
> 
> Saves me having to deal with your blog stuff that is not about
> Aboriginal development.  I'm a compulsive reader, and avoiding
> temptation is always good.  B-)

Seems vaguely unanimous...

Rob