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

[Rob Landley]

On Wednesday 11 October 2006 2:34 am, Dave Dodge wrote:
> On Mon, Oct 09, 2006 at 12:39:12AM -0400, Rob Landley wrote:
> > I don't see how this is significantly different from a docbook to
> > pdf converter.
> 
> Well, it's about a 1000 times easier to install than anything to do
> with docbook :-). I've been known to edit software packages to remove
> dependencies on docbook because it's such a nightmare to get the
> blasted thing in place.

I didn't say docbook was a good example. :)

I just don't see why what machine you're running the compiler on is any of the 
compiler's business.  It should only care what machine it's producing target 
binaries for.  So the difference between cross-compiling and native compiling 
is pretty darn artificial, from the compiler's point of view.  (Now building 
a package _with_ a compiler has to care about whether or not it can run what 
it's building, but that's still not the actual compiler's problem.)

> > It sounds like you made it run on x86-64, from which it can
> > presumably produce binaries for x86, arm, and whatever the heck c67
> > is?
> 
> As much as I love the idea of a trivial cross-compiler, there are some
> gotchas.  For example it has to be sure to use header files that match
> the target machine's libraries.

And the libraries you're linking against have to be target libraries too.

I didn't say that the _only_ input files were the ones listed on the command 
line.  You have #include directories and library directories.

There are generally two #include directories, one for your C library and one 
for the compiler-related header files like varargs.h.  There are generally 
also two library directories: one for your system libraries and one for your 
compiler's libraries (like crt0).  Personally, I think this distinction is 
somewhat artificial and you can dump 'em all in one directory without too 
much trouble, but it's no sillier than the distinction between "/lib" 
and "/usr/lib" and specifying a colon-separated path is easy enough.  
(Probably a good idea to stick the compiler's built-in stuff at the front.)

But this is not brain surgery.

> There's also minor variations in the 
> architecture support itself, for example the Win64 ABI is LLP64 on
> x86_64 instead of the LP64 design that everyone else uses.

And you have a code generator backend.  Currently specified by the name of the 
compiler binary you're running, but "-m arch" would work too.

alias cross-compiler "tcc -I /blah:/blah -B /blah/blah/blah -m arm-wombat"

Sane defaults remain a good thing, so you'd probably want some kind 
of "-nostdcrap" argument at the start of that...

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