[Aboriginal] Aboriginal Digest, Vol 24, Issue 3

[Isaac Dunham]

On Mon, 14 Jan 2013 07:27:17 -0600
Rob Landley <rob at landley.net> wrote:


> > > I was looking up sparc64 a while ago and it's another one like  
> > powerpc
> > > 64 where they didn't bother to do a 64 bit userspace, just 64 bit
> > > kernels and the very occasional application. Thus I'm not quite sure
> > > how to add Aboriginal support to it. (Just a toolchain? Toolchain  
> > and
> > > kernel using the 32 bit userspace? Except how would you build the
> > > "occasional" 64 bit application? Where does libc enter into this?)
> > >
> > >    http://www.debian.org/ports/sparc/
> > 
> > Debian's approach is "multilib", but that's a bit of a mess in its  
> > own right.
> > You might need their patches to make it work right.
> 
> I don't do multilib. I'm trying to set up a target environment you can  
> build stuff under. If you can natively build a new Linux From Scratch  
> chroot, my work is done.
> 
> > Basically, you have
> > -a 32-bit toolchain, but capable of targeting both 32-bit and 64-bit
> > -two builds of libc, one for 64-bit, one for 32-bit
> > -the rest of the environment built for 32-bit
> 
> 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?
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."

> > > Then again, I'm told that's changing because gcc is dropping sparc32
> > > support:
> > >
> > >    http://wiki.debian.org/Sparc64
> > >
> > > (Of course current gcc requires a C++ compiler on the host to build  
> > it,
> > > so here's hoping clang/pcc/open64 matures quickly.)
> > 
> > What's left for open64 to mature in your opinion? From all I've seen,  
> > there are a
> > few places where gcc is just catching up with them.
> 
> I don't know. I'm trying to learn enough to find out. I'll probably  
> have to try it and see what breaks.
> 
> > 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.

All the alternate compilers currently require gnu binutils.
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.

elftoolchain is not really useful yet, though there's an ar implementation and some code towards ld.
Somewhere else I ran across a linker based on llvm. I wish I could remember its name...
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."
I guess that means they're finally working on getting rid of the binutils dependency.
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


> Rob

-- 
Isaac Dunham <idunham at lavabit.com>


 1358185812.0