[Aboriginal] Aboriginal Digest, Vol 24, Issue 3

Rob Landley rob at landley.net
Mon Jan 14 16:03:09 PST 2013

On 01/14/2013 11:50:12 AM, Isaac Dunham wrote:
> On Mon, 14 Jan 2013 07:27:17 -0600
> Rob Landley <rob at landley.net> wrote:
> > If I _can_ build a 64-bit only environment, I'd like to do that.  
> That's
> > how the x86-64 target works, for example. (You can add 32 bit  
> libraries
> > after the fact, by building them  natively on target.)
> >
> > Last I checked uClibc didn't support it, but musl might someday.
> "it" == building only 64-bit libs when targeting 64-bit arches?

"it" == sparc64, but possibly I was thinking ppc64 or s390.

To support something in aboriginal I need toolchain, libc, qemu, and  
kernel support. I need to get the kernel and qemu to agree on a board  
emulation with the appropriate I/O devices, and I need userspace, libc,  
and kernel to agree on a system call interface with a consistent  
floating point implementation.

> If so, that's all that musl supports; there is no automated "we think  
> you ought to
> support another ABI, so we're building it also."

That's not libc's job, if you wanted to support both you'd build it  
twice with two different compiler output modes and then ahve parallel  
library search paths ala /lib32 and /lib64 and that's what I don't do.  
(I just do the lib64 and then if you want to add lib32 natively on  
target you can do so after the fact. See the x86_64 image as an  
example, it's got kernel support for 32 bit syscalls but not a 32 bit  
library or toolchain. So you can drop static 32 bit binaries on there  
and run them if you like, but if you need a 32 bit chroot you need to  
supply it yourself. I have one in i686 and you can extract the i686  
tarball on there, but integrating them is left as an exercise for the  

> > > clang seems to be making headway, but pcc seems to be at the  
> "well,
> > > it's more
> > > active than tcc..." level. It can bootstrap at least OpenBSD,  
> though,
> >
> > Clang needs C++ on the host in order to build (but only recently  
> wrote
> > its own C++ standard library), didn't have its own binutils last I
> > checked... I'll need to engage with this more at some point but it's
> > not strongly luring me out of my niche yet.
> clang's libc++ apparently still requires libsupc++ at least on linux;  
> the
> equivalent library for clang runs on OSX/*BSD, but is experimental on  
> Linux.

There are reasons clang is still on my todo list. Clean  
self-bootstrapping really isn't high on their todo list. (Building a  
linux kernel is still one of those crotchety not-quite-supported things  
of the "somebody says they got it to sort of work once" variety.)

> All the alternate compilers currently require gnu binutils.

Tinycc doesn't. Alas, I need a spare year on a desert island to do qcc.

> Clang/LLVM have no plans to address this that I can see.
> pcc is the closest to not doing so, since it can use yasm as  
> assembler, but this is
> pretty limited in application and requires a linker.

It also requires lex and yacc to bootstrap, last I tried it.

> elftoolchain is not really useful yet, though there's an ar  
> implementation and some
> code towards ld.

Dunno that one.

> Somewhere else I ran across a linker based on llvm. I wish I could  
> remember its
> name...

I need to read the GOLD development blog entries. (I've read something  
like the first 3, then bookmarked it...)

> Hmm...lld.llvm.org claims that "In the same way that the MC layer of  
> LLVM has removed
> clang’s reliance on the system assembler tool, the lld project will  
> remove clang’s
> reliance on the system linker tool."

Apple wants to brick up GPL's corpse in the basement wall because  
GPLv3. I can't blame 'em.

> I guess that means they're finally working on getting rid of the  
> binutils dependency.

It's a todo item. We all have our lists...

> Ah, that's what I wanted:
> http://code.google.com/p/mclinker/
> 1/8 the size of binutils, "designed for on-device compiling"  
> (specifically mentions
> low memory use), supports arm/mips/x86

Cool, but binutils contains a half-dozen things and an assembler is a  
fairly important one of those.

Also, the reason my qcc idea glued QEMU's Tiny Code Generator to the  
tinycc front-end was to leverage the target support the qemu guys do.  
They've got sh4, sparc, s390, cris, and so on. Large existing  
development team, leveraging their work would be really nice.


More information about the Aboriginal mailing list