[Aboriginal] new user on the list (with questions)

Thu Apr 7 17:56:54 PDT 2011

On 04/07/2011 10:59 AM, Bjørn Forsman wrote:
> Hi Rob,
> 
> Thanks for that long (and quick!) reply! Please don't think I'm rude
> just because my reply won't be nearly as long :-)
> 
> 2011/4/7 Rob Landley <rob at landley.net>:
>> On 04/07/2011 01:33 AM, Bjørn Forsman wrote:
>>> Hi Rob,
> [snip]
>> I've actually been meaning to take openembedded and buildroot and such
>> and treat them as small distros: try to chop off their "what you build"
>> and "how you build" bits to convince them to natively build their
>> packages on an unknown target.  I.E. treat buildroot like koji or
>> catalyst: something that populates a chroot using the host's native
>> toolchain.
> 
> You mean creating buildroot and OE control-images? (I wasn't expecting
> that after the "accidental distro" thing.)

Whether or not they meant to be distros, they are distros, with existing
userbases and development communities.  Creating control images for
their distro parts would let people use them as distros without having
to rely on their ability to bootstrap new hardware.  (I.E. separating
those roles and focusing on _just_ their existence as a distro.)

I'm trying not to let _my_ project get sucked into the trap of becoming
a distro and losing focus on terraforming new hardware platforms.  (It
still seems to confuse people that you can have a tool that
intentionally does just that and nothing else.)

>>> * Where is the hg clone URL for Aboriginal Linux?
>>
>> hg clone http://landley.net/hg/aboriginal
> 
> Ah, so it's the same as the webUI! I was so close to trying that :-)

Mercurial is very simple.  Learning git first gives you a bunch of
horrible assumptions.  (Why WOULD you have two urls for the same
repository?)

>> At the top of my todo list is finishing gentoo-boostrap because A) I've
>> already done half the work for that (and 2/3 of the research), B) it
>> builds from source already.
> 
> What's missing in gentoo-bootstrap? (I haven't tried it yet.)

Um, been a while, lemme check my blog:

  http://landley.net/notes-2010.html#08-09-2010
  http://landley.net/notes-2010.html#12-09-2010
  http://landley.net/notes-2010.html#15-09-2010
  http://landley.net/notes-2010.html#01-12-2010

That should give you a flavor of it.  I haven't honestly poked at it
since last year, still trying to get lfs-boostrap to work on all
hardware targets, which means upgrading uClibc...

> It's really nice that Gentoo has one package metadata repository for
> all ARCHs (they do right?), but having a package manager written in
> python feels bloated for embedded systems.

There's a C version, it just doesn't work as well.

And their repository format is... "interesting".  It needs a redesign
for scalability.  Unfortunately, Solar's burned out and the other
maintainer of gentoo-embedded (Mike Frysinger) has such horrible
engineering taste that you can almost reliably determine the correct
course of action by what he argues AGAINST doing.

> Archlinux is pretty easy to build from source also (see Arch Build
> System). But upstream Archlinux doesn't care about other architectures
> than x86/x86_64 though, so that's a minus.

If we come up with a native bootstrap script, then they wouldn't really
have to, would they? :)

>> After that probably Debian/Ubuntu, becuase thats what I use on my laptop
>> and Ubuntu is the most popular Linux distro with somewhere around 40%
>> market share.  (And considerably higher among developer workstations.)
> 
> Great! I'm glad you're planning more bootstraps.

Yeah, gotta make the time though.

Linux From Scratch built a bunch of packages which found a lot of bugs
(the analogy of driving a flock of sheep across a minefield comes to
mind).  Unfortunately, a lot of the bugs it found are in uClibc's
pthreads implementation, which on many of the more obscure platforms
isn't reliable and makes the build unreliable.  (Make uses threads and
even make -j 1 has a worker thread which the parent waits for, and if
the locking isn't reliable stuff happens out of order every once in a
while and miscompiles stuff or breaks the build.)

  http://landley.net/notes-2010.html#17-12-2010

Since pthreads is going away in favor of NTPL, trying to debug the old
threading implementation isn't very useful.  This means my priority is
getting uClibc-NPTL to work, then making bootstrap-LFS build reliably on
all my hardware targets, then getting back to trying to make the
half-finished gentoo bootstrap work.  (I might do BLFS in there first as
low-hanging fruit, but if I can't even build the full LFS reliably on
mips or powerpc right now....)

>> By the way, I'm currently stuck on the last gplv2 release of binutils
>> and gcc the same way I was stuck on busybox 1.2.2.  (I'm never going to
>> contribute to any GPLv3 licensed project unless paid, and I'm not
>> comfortable shipping binaries of that stuff.)  Unfortunately that means
>> I can't do armv7 and the microblaze targets.
> 
> Really? Why is it so bad? Does using a GPLv3 compiler mean the
> produced binaries are also under GPLv3?!

Well, yes:

  http://lwn.net/Articles/343608/

But for me it's more:

  http://www.landley.net/notes-2006.html#03-12-2006

>> I'm subscribed to the pcc
>> mailing list and I check in on llvm/clang from time to time, and I
>> really hope one of those unseats gcc.  (That's why I was working on
>> tinycc, but Grischka's permanently rendered that project irrelevant.)
> 
> It seems pcc doesn't support any ARM targets on linux and clang only
> support ARMv6 and ARMv7. (I'm mostly into embedded linux because of
> ARM...). I wonder when they get better ARM support.

They're new.  More target support should come in time.

Really what I wanted to do was this:

http://tree.celinuxforum.org/pipermail/celinux-dev/2009-December/001924.html

Leverage QEMU's target support in tcc, and suddenly yo have a compiler
that supports everything.  (It may not produce very efficient output,
but if the whole compiler is a single 100k binary that's forgivable.)

Yet ANOTHER project I haven't had time to pursue.  It'd be nice if
somebody would...

>> Using crosstool-ng would be a great workaround for that.  They do
>> toolchains so I don't have to.  And if ALL they do is toolchains: great,
>> leverage it.  (But I need cross and native, and I'm picky about 'em, and
>> I still need to build my own C library because uClibc ain't fully cooked
>> yet, and ccwrap.c is a better approach than trying to get gcc's path
>> logic to _EVER_ work...)
> 
> Yes, I think crosstool-NG has a clearly defined scope. BTW,
> crosstool-NG also do a bit of canadian-cross:
> http://ymorin.is-a-geek.org/projects/crosstool#canadian_build
> http://ymorin.is-a-geek.org/hg/crosstool-ng/ct-ng.canadian/

My native-compiler.sh and cross-compiler.sh scripts are technically
doing canadian cross as well.  That's a normal part of building toolchains.

In 2008 I hosted a compiler BOF at OLS that turned into me ranting for
an hour (didn't _mean_ to but they kept asking me questions as if I knew
stuff):

  http://landley.net/talks/ols2008-rob-landley-linux-compiler.ogg

One of the topics was how compilers SHOULD work.  (Read input files,
produce output files.  Just like a docbook to pdf converter.  There's
nothing special about this, and compiler developers who think there IS
are doing it wrong.  Thus half the distinction between "native" and
"cross" compiling is needless confusion based on people who think what
they're doing is magic when it isn't.  I blame the FSF, as usual.)

The hard part of design is figuring out what NOT to do, and how.

Rob

 1302224214.0