Comment # 3 on bug 1198120 from Michael Matz

(In reply to Johannes Krottmayer from comment #2)
> 
> It works, for Linux with the DEFAULT configuration with Kconfig, because in
> the default config Linux implements it's own libgcc... But I can also
> specify in the Kernel configuration, to use the GCC libgcc and then you get
> many undefined reference linker errors, with this pseudo cross compiler.
> Sorry, I'm upset because this  wrong configuration.

What is "wrong" is the naming of our packages: instead of "-cross-" they should
have been called "-icecream-backend-" or the like, because that is what they
exist(ed) for.  They never were and for most architectures still aren't
intended
to be usable as a normal cross compiler.

We're sorry for leaving the wrong impression with that package name, but it has
historic roots and there isn't (or wasn't) enough incentive to change the
naming.

Currently we're (on and off) working on changing the whole setup of cross (or
pseudo-cross) compilers.  But that will still be so that only some target
architectures will exist as full proper glibc-based cross compilers.  The rest
will remain free-standing-only or even just icecream-backend-only cross
compilers.  (The difference is basically that the icecream backends are never
used for linking target code, and hence don't need and don't have any of the
target libs, e.g. libgcc).

So, to determine which targets to include in which list, what's your target?
Is it really cross-compiling _to_ x86_64?  As you're using Windows 10, also
on x86_64, why aren't you just using the normal native compiler?

> But what is with other tools? GRUB? I'm currently don't know the source
> code. But when GRUB don't use it's own config, the linking also fails...

Yes, linking fails.  The icecream backends aren't supprting linking target
code,
and that it works with the kernel, in some configurations, is only a happy
(but generally unsupported) accident.