[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
user.)
> > > 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.
Rob
1358208189.0
More information about the Aboriginal
mailing list