[Petr Baudis]
> I'm a bit lost here - the kernel uses tons of gcc extensions - how is
> another compiler supposed to understand them? And if it is
> specifically extended to understand them, isn't it likely that it'll
> understand the -shared switch in gcc-like way as well?
There is a difference between $(CC) and $(HOSTCC). We have both of
them for a reason. $(CC) specifies the compiler used to build the
kernel - it may or may not be your regular system compiler. It can
even be for another architecture - for example, it may produce PowerPC
object files from the comfort (?) of your x86 PC.
$(HOSTCC) is specifically to build executables that are to run *on* the
build system itself - kconfig, for example. If you're running on x86
and building a PowerPC kernel, you need an x86 version of kconfig, not
a PowerPC version.
So $(CC) *must* be a gcc (or a convincing facsimile) - but $(HOSTCC)
can be *any* C compiler on your system. I don't think anyone tries to
use any gcc extensions with $(HOSTCC).
> And how likely is situation when someone want to configure a kernel
> with non-gcc compiler and actually build it with gcc?
Not very likely, but you take a lot for granted. On many combinations
of Unix + gcc versions, `gcc -shared' doesn't work until you spend half
a day hand-tweaking the specs file whilst poring over the obscure flags
section of the `ld' manpage. Try it for gcc 2.95 on AIX sometime, for
a bit of good clean fun.
My point was and is that while shared libraries are a (relative!)
breeze on Linux, they have always been a horrible portability headache;
furthermore, the kernel build system doesn't need them and ought to do
without.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:49 EST