[Dev] Fix host architecture to x86_64 for building arm target
myungjoo.ham at samsung.com
Mon Dec 12 02:28:46 GMT 2016
>On Mon, 12 Dec 2016 01:43:37 +0000
>MyungJoo Ham <myungjoo.ham at samsung.com> wrote:
>> In order to build dotnet-core runtime (coreclr) armv7l/Linux with
>> crosscompilers, the building environment should be x86-64. x86-32
>> simply cannot support it because dotnet-core runtime does not support
>> x86-32; you need to run dotnet-core itself to build dotnet-core (to
>> build mscorlib.dll for target arch)
>this is what i don't get. MONO (which is what xamarin was actually
>build on top of) runs on armv7. even armv6. it also has run on i586 for
>years and years. dotnetcore if it requires a jit to run (a CLR
>jit) ..then there already is one - MONO has had it for years.
That was about cross-compiling. Even for MONO, crosscompiling MONO
is far-more faster than qemu-native-copmiling MONO. In Tizen OBS/GBS
environment, packages using GCC (including MONO) gets automatically
crosscompiling supports from qemu scripts. Our Tizen OBS/GBS simply
didn't enable that for LLVM, yet.
One more major difference is that you only need GCC to build MONO.
In order to build MONO completely, you need MONO; however, you can build
"mono basic" without MONO, which can be used to build the complete MONO.
Thus, you do not have the bootstraping issue with MONO as long as you
have normal building infstructures: GCC and its friends.
But, in dotnet-core, you need more than that. You cannot build dotnet-core
(coreclr + mscorlib + corefx) without themselves (coreclr + mscorlib + corefx),
thus, you must have them "built" before building them: the bootstraping issue.
Or you can let the build scripts to download the latest & stable
versions of whatever required. (x64 / aarch64. I expect armv7 is going to be
added soon; I just cannot sure whether they'd include armv7l or not.)
>or is this the difference between MONO and microsoft's own dotnet-core
>which is far more limited in platform support? this is a specific
>limitation of microsft's code? i am unfamiliar with what EXACTLY
>dotnet-core is but i suspect it's microsoft's own implementation.
>but i DO know MONO has built for and run on a massive range of
>architectures for years and years... even back when x86_64 was very new
>and shiny and it had to support i586 as that was the vast majority of
>the PC market.
With the new JIT architecture, RuiJIT (dragon JIT?), they have abandoned
32bit architectures (x86-32 & armv7). JY and collegues are reviving armv7l
for RuiJIT. If I remember correctly, RuiJIT was much more efficient than
Mono especially with its garbage collection in x86-64 benchmarks.
And I 'believe' there were non-technical considerations as well,
including that mono's main contributing company is acquired by dotnet-core's
main contributing company.
>> You may try to build dotnet-core armv7l/Linux at ARM(armv7l);
>> however, the dotnet toolchain for armv7l is not released officially
>> via the official sites (are they releasing ARM/Linux officially these
>> days?), which means that you cannot reuse the toolchain release infra
>> and the default building scripts, which automatically updates
>> dotnet-core toolchains via the Internet. You need to rebuild the
>> whole toolchain sets for your toolchain sets. (build dotnet-core
>> ARM/Linux to build dotnet-core ARM/Linux for every major updates in
>> dotnet-core ARM/Linux). Besides, building dotnet-core ARM/Linux at
>> armv7l-qemu at x86-64 takes x10 times of building dotnet-core
>> ARM/Linux directly at x86-64 (with crosscompiling toolchains). It's
>> 10 min vs 100 min in my desktop.
>so why not use MONO? :) it almost sounds like we've chosen a far more
>limiting codebase than a far better supported one. especially for our
>needs of supporting multiple architectures...
>> With the default configurations of qemu accelerations, OBS/GBS uses
>> x86-32 for armv7l, which is not suitable for dotnet-core armv7l.
>> Thus, in order to reuse MS's toolchain infrastructures and in order
>> to accelerate building dotnet-core, they might want to use x86-64 for
>> dotnet-core armv7l.
>> ps. I'd been away from dotnet-core for a while. So, JY, please
>> correct me if things have been changed. (e.g., did they start
>> supporting x86-32 or so..)
More information about the Dev