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

Carsten Haitzler c.haitzler at samsung.com
Mon Dec 12 04:36:51 GMT 2016

On Mon, 12 Dec 2016 03:49:25 +0000
MyungJoo Ham <myungjoo.ham at samsung.com> wrote:

> >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.  
> I didn't say you cannot build dotnet-core arm at arm. I was saying why
> they didn't want to build dotnet-core arm at arm. (and x86-32 cannot
> build it)
> The real problem what JY met is that OBS/GBS runs x86-32 for armv7l
> and x86-32 (not armv7l) does not support dotnet-core.
> And if they give up using qemu-accel (or equivalent) for dotnet-core
> (in fact, LLVM/Clang for qemu-accel), there is no issue.
> They can simply build the whole dotnet-core with GBS/OBS, which
> is already done and had been doing so for a while.
> In short, you can build dotnet-core arm at arm, with or without
> GBS/OBS. That's what Tizen dotnet-core folks had been doing for a
> while ago. (I'd been building it in TM1 as well)
> What I suppose JY and collegues trying to do is to avoid building it
> in ARM & x86-32 environment, not because of the RAM size, but because
> of build efficiency with qemu-accel+cross-compiling.

ok. if it's just efficiency then that makes sense. what i was worried
about was that it sounded like it was literally not possible... :)

More information about the Dev mailing list