mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Andrew Bradford <andrew@bradfordembedded.com>
To: musl@lists.openwall.com
Subject: Re: embedded newbies site.
Date: Mon, 22 Jul 2013 08:27:56 -0400	[thread overview]
Message-ID: <1374496076.9947.9223372036855616493.718EFEA9@webmail.messagingengine.com> (raw)
In-Reply-To: <CA+wkPBSVF1nbB5DO9fJZo5NzQxYCMr3tw8pQAdUyjovxpoQNjQ@mail.gmail.com>

On Sat, Jul 20, 2013, at 11:17 AM, James B wrote:
> On Tue, Jul 16, 2013 at 10:18 AM, Strake <strake888@gmail.com> wrote:
> 
> > On 15/07/2013, Rob Landley <rob@landley.net> wrote:
> > >    - creating a development environment (building binutils, gcc,
> > > make...)
> > >      - requirements for self-hosting
> > >      - requirements for natively building Linux From Scratch
> > >      - cross vs native compiling
> > >        - bootstrapping to native compiling under emulation.
> >
> > This. For me, at least, this is often the greatest hindrance.
> >
> > That makes two of us. There are many tools for making cross compiler
> (aboriginal, crosstools-ng, buildroot, etc) but I haven't found one that
> guides how to move to native compiling (=create the native compilers)
> once
> one has the cross-compilers and bootable rootfs (I know, aboriginal
> *does*
> create native compilers so I should read Rob's scripts for that ...).
> 
> That being said, the other topics are pretty relevant too.
> 
> Also, anyone thinks that CLFS is good start for this? One thing that I
> notice about (C)LFS is that the steps are there but the rationale and
> explanation isn't; so it encourages people to follow a recipe without
> knowing *why* things have to be done in a certain way (to be fair, the
> main
> LFS (not its CLFS variants) does have some kind of explanation but it
> could
> be improved).

I'm currently one of the only developers currently working on the CLFS
Embedded book [1].  I'd happily take patches to describe why things work
they way they do and why the steps are what they are.  The biggest
hindrance the CLFS embedded book has is a lack of both developer time
and experience, the main core people who started the embedded book
haven't contributed much in the past few years I assume due to other
commitments.

[1]:http://cross-lfs.org/view/clfs-embedded/

We're (2 or 3 of us) currently in the middle of a bunch of discussions
on #cross-lfs IRC and scattered around clfs-dev ml regarding moving from
uClibc to something else.  I tried some builds with glibc and realized
that's not really a decent choice, even today.  I got pointed to musl by
rofl0r on Github (sorry, don't know their real name).  We're now working
though coming up to speed on musl and learning how to build it such that
we can consider it for use on MIPS, x86 and ARM for the book [2].

[2]:http://lists.cross-lfs.org/pipermail/clfs-dev-cross-lfs.org/2013-July/001517.html

If the CLFS embedded book is a good starting point, please feel free to
send patches, I'm happy to take them.  Although based on reading through
the archive it looks like the real goal is bigger than what CLFS
embedded's real goals are: like talking about jtags, emulated
bootstraps, native compilers, etc.

If CLFS embedded isn't the right place to start, maybe deprecating the
CLFS embedded book and moving to the proposed wiki would be something to
consider?  Especially if the developer time / experience is higher and
if the final product would cover more of the "why" and not just the
steps.  I'd be happy to contribute to such a resource where I can.

Thanks,
Andrew


  reply	other threads:[~2013-07-22 12:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16  2:03 Rob Landley
2013-07-16  3:18 ` Strake
2013-07-17 12:07   ` LM
2013-07-17 13:58     ` Rich Felker
2013-07-20 15:17   ` James B
2013-07-22 12:27     ` Andrew Bradford [this message]
2013-07-22  4:40   ` Rob Landley
2013-07-23  0:12     ` Strake
2013-07-27  0:58       ` Rob Landley
2013-07-27  2:01         ` Strake
2013-07-27  2:50           ` Rich Felker
2013-07-29 20:01             ` Rob Landley
2013-07-29 19:54           ` Rob Landley
2013-07-30  1:35             ` Strake
2013-08-01  6:20               ` Rob Landley
2013-08-03 16:52                 ` Strake
2013-07-16 11:50 ` LM
2013-07-16 13:56   ` Szabolcs Nagy
2013-07-16 14:00   ` Rich Felker
2013-07-16 17:49   ` Strake
2013-07-22  6:00   ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1374496076.9947.9223372036855616493.718EFEA9@webmail.messagingengine.com \
    --to=andrew@bradfordembedded.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).