[Dev] Fix host architecture to x86_64 for building arm target

Carsten Haitzler c.haitzler at samsung.com
Mon Dec 12 03:05:24 GMT 2016

On Mon, 12 Dec 2016 02:28:46 +0000
MyungJoo Ham <myungjoo.ham at samsung.com> wrote:

> >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.

not talking speed here. just "can it". of course running a qemu arm
emulator on x86 to emulate arm binaries is silly (and we've been doing
this for a long time for binaries that should have become native to the
build host).

what worries me is more "if you now built on an arm host or a mips host
etc." what would happen? all the distro build systems and setups i have
ever worked with would not have issues here. they will work. what i am
wondering is if this is going to simply make parts of tizen "only able
to be built on x86-64 as a cross-compile and in no other way" and THAT
would be a big problem.

i understand that some things need awfully huge amounts of ram to
build. let's not combine that with an architecture issue.

> 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.

yeah. so what are the issues for dotnet-core. do they try and do both
at once rather than breaking it up into stages?

> 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.)

oh... this sounds... bad. what about arvm8? etc. - can't you bootstrap
some other way?

> >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.

oh sure. not talking efficiency here. simply "being able to bootstrap
cleanly". can you use mono to bootstrap coreclr somehow? and yeah - i
know the xamarin -> ms deal. mono still exists as open source.

at least until dontent-core/coreclr has a good and healthy set of
bootstrapped code for all the major architectures we need to support
(where we can both build and run on them) so to me that means
definitely armv7 and arm64, likely mips32 and mips64 too. x86-64 just
is a "because we can" at the moment realistically and i586 also
"because we can", but if they literally removed all 32bit support from
the JIT then that's a problem. it's definitely for armv7...

this is basically the question i was originally asking. the JIT in
dotnet-core has dropped all 32bit support. you of course need a running
JIT to then run the already bytecode compiled blobs to further build
more stuff. got it.

so my question the is... can we just bootstrap and use mono's clr engine
for now just for build purposes (and not runtime on the target)? the
code is there and is open soruce and is not going to vanish. at least
it will keep things working across architectures UNTIL coreclr is fully
bootstrapped back to normal (and it can still be used for i586) :)

> >> 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.
> >> 
> >> 
> >> Cheers,
> >> MyungJoo
> >> 
> >> 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 mailing list