Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so

[Peter Samuelson]

[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