What's that "GNU/Linux" in the beginning? [LWN.net]

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 17:37 UTC (Fri) by nix (subscriber, #2304)
In reply to: What's that "GNU/Linux" in the beginning? by gnb
Parent article: The Ultimate Distro (Linux Journal)

The build system is a good bit less 'interesting' than it used to be (although still quite hairy). (Not that GCC is devoid of cruft in other areas, of course...)

(Log in to post comments)

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:54 UTC (Fri) by landley (subscriber, #6789) [Link]

The gcc build system sucks rocks, I've just learned where to hit it with
a large stick.

A compiler is a program to turn input files into output files. It takes
multiple sources of input (c source, header files, libraries), but so
does a docbook to PDF converter that needs fonts or style sheets.
There's no fundamental difference between the two.

If compiling the docbook to PDF converter cared a lot whether it was
running on ARM or Mips or Sparc it would be broken and unportable. But
you can't configure gcc to say "build arm files" without telling it "and
you're running on i386" as if it makes a huge difference.

The difference between a cross compiler and a native compiler is hugely
artificial, and gcc's insistence on being told --host as well as --target
is stupid. The fact it can be told _three_ (--host, --target,
and --build) is just _crazy_. And its insistence that if --host
and --target are the same string then you're obviously not creating a
cross compiler, so build everything differently, is just _evil_. (Hello,
host has glibc, target has uClibc. The dynamically linked binaries
you're producing won't run on the host because uClibc isn't installed.
YOU ARE CROSS COMPILING.) One of the reasons I like tcc is that it
doesn't make a big deal about this: configure it to produce arm binaries,
build it _with_ a compiler that links it against uClibc, and it just
works. There doesn't have to be a special name for doing that ("canadian
cross") because it's NOT A BIG DEAL.

If the current gcc build system is a distinct improvement over what came
before, we are _beyond_ "damning with faint praise".

And don't get me started on its' path search logic.

What's that "GNU/Linux" in the beginning?

Posted Jan 9, 2007 17:34 UTC (Tue) by nix (subscriber, #2304) [Link]

The path search logic has just got a little cleaner :)

Of course it makes a difference what the build system is: it needs to know if the files it builds to incorporate into the (many) little-language code generators it builds and uses during the build process can also be linked into the final compiler binary. It needs to know if a three-stage bootstrap is even *possible* or whether `make' should invoke a one-stage build (`make bootstrap' is so 2004, y'know, it's just `make' like every other package these days). It needs to know if there are any differences between e.g. the floating-point representation used on the build and host system. It needs to know if it can run configure tests to determine properties of the host system, or whether it has to assume safe defaults (you wouldn't want it doing the latter in the common case). (tcc doesn't need to do this to such a degree because it doesn't come with a bunch of runtime libraries. Also it doesn't need to cater for the nest of snakes which is exception unwinding and the related nest which involves shared libraries, destructor invocation order, and so forth.)

And as for the distinction between a native and cross-compiler being artificial, well, in *theory* a compiler could be made that didn't care what its host system was, but in practice unless it is to be intolerably slow it *must* know the machine's native types at least (which varies between OS and platform because it is ABI-dictated, and on many platforms GCC/binutils do not set the ABI). (A sufficiently nonportable compiler could avoid paying attention to systems that don't have IEE754 floating point, but GCC is not that nonportable, or at least at one point it wasn't: I'm not sure how many non-IEEE754 systems are left. I think some are, discounting ia32/x87 of course with its horrible `extended precision' mess, which is slowly becoming legacy anyway as SEE fpmath takes over.)

The `target triplet' stuff GNU has got is a bit ugly, but if you consider it to be an `ABI-and-OS-and-core-libraries indicator' (which is basically what it is), then it makes a bit of sense. uClibc just needed a new target triplet/quadruplet (and, oh look, *-*-*-uclibc works perfectly well).