Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).

[Rob Landley]

On Friday 13 October 2006 12:12 am, Dave Dodge wrote:
> There's still some slightly tricky bits, because -m has some
> interactions/dependencies on the compiler's header files and the -I
> and -m options are therefore not completely independent.  In the
> particular case of Win64 vs. 64-bit Linux on the same target machine,
> compiler-related values such as ULONG_MAX would be different.

Are there more users of Win64 than there are of Itanic?  I had a 3-month 
contract with Dell at the start of 2005 and my impression was they couldn't 
_give_ Win64 away.

Maybe it's picked up since.  I still don't personally care...

> Perhaps more complicated than it's worth, is the idea that the
> compiler header contents can be built into the compiler and generated
> internally at runtime based on the architecture selection.

Not going there.

> C doesn't 
> actually require there to be disk files for things like "limits.h" --
> it just says that the directive "#include <limits.h>" causes certain
> things to become visible to the translator somehow.

Or we can chop up one set of files with #ifdefs based on architecture type.  
Or we can just have more than one set (possibly produced by running a variant 
of unifdef on the version with lots of #ifdefs).

> > Sane defaults remain a good thing, so you'd probably want some kind 
> > of "-nostdcrap" argument at the start of that...
> 
> Yes, and you want to be sure it's truly independent of the host
> environment.

That's just a question of testing on lots of targets and fixing problems as 
they come up.

> As you're probably aware, in the past it's been 
> notoriously difficult to configure a GNU toolchain

You can stop that sentence right there. :)

> to be 100% divorced 
> from the host environment.  For example if you want to cross-link
> against uclibc while running on a glibc system with the same target
> hardware, I think the only reliable way to do it is by chrooting into
> a uclibc host environment.

Or by running sed against the source code repeatedly while building it.  (I've 
done this.)

I've pointed out for years that the split between gcc and binutils is 
historical and political, not technical.  Recently my coworkers have made the 
case that the split between gcc and glibc is largely theoretical these days, 
although more than half of that is on the glibc side...

FSF projects tend to leak dependencies on other FSF projects.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery