On Mon, 12 Dec 2016 01:43:37 +0000 MyungJoo Ham <myungjoo....@samsung.com> wrote:
> >On Fri, 09 Dec 2016 05:58:22 +0000 > >윤지영 <jy910....@samsung.com> wrote: > > > >> > >> > >> --------- Original Message --------- > >> Sender : 하이츨러 <c.haitz...@samsung.com> Master/S/W > >> Platform팀(S/W센터)/삼성전자 Date : 2016-12-09 14:34 (GMT+9) > >> Title : Re: [Dev] Fix host architecture to x86_64 for building arm > >> target > >> On Fri, 09 Dec 2016 05:28:19 +0000 > >> 윤지영 <jy910....@samsung.com> wrote: > >> > >> > > >> > > --------- Original Message --------- > >> > > Sender : 하이츨러 <c.haitz...@samsung.com> Master/S/W > >> > > Platform팀(S/W센터)/삼성전자 Date : 2016-12-09 12:08 (GMT+9) > >> > > Title : Re: [Dev] Fix host architecture to x86_64 for > >> > > building arm target > >> > > On Fri, 09 Dec 2016 03:05:54 +0000 > >> > > 윤지영 <jy910....@samsung.com> wrote: > >> > > > >> > > > > >> > > > Dear all, > >> > > > > >> > > > > is it x86-64 that it needs or just a large memory address > >> > > > > space (like chromium for example)? > >> > > > > >> > > > .NET is a little different. > >> > > > At present, .NET only provides toolchains for x86-64. To > >> > > > create arm binaries for .NET runtime and libraries, x86-64 > >> > > > libraries are needed in the GBS arm environment. To do so, > >> > > > we use the qemu-accel package for x86_64, which installs the > >> > > > libraries for x86-64 in /emul/ directory on arm GBS > >> > > > environment and .NET toolchains link them. > >> > > > > >> > > > We have tried to support .NET toolchains for arm. However, > >> > > > even if we have .NET toolchains for arm, there is a high > >> > > > possibility of using x86-64 toolchain as usual due to build > >> > > > speed issue. In the light of our experience, it took more > >> > > > than 24 hours to build the runtime, but it did not > >> > > > succeed. > >> > > > >> > > ok but it isn't something specific like "it uses x86-64 > >> > > assembly and thus only works on x86-64". it's just a question > >> > > of building the toolchain for arm or i586 or mips or any other > >> > > architecture - right? > >> > > >> > More specifically, it does not create a toolchain for arm. > >> > The toolchain runs on x86_64 called 'dotnet' creates arm > >> > binaries and C# managed dlls. > >> > >> > but can the toolchain be built for arm? can it run on arm? does > >> > it ONLY run on x86-64 - why only on x86-64 if so? > >> > >> At present, the toolchain for arm is not available and we are > >> trying to support it as soon as possible. If it is provided, it > >> can, of course, run on arm. However, even though the toolchain for > >> arm is provided, we are considering using the toolchain for x86_64 > >> for build acceleration. > > > >ok. so i'm curious... why is it "not provided" what needs to be done > >to make it work? is this like luajit where it has architecture > >specific assembly for it's core and so needs to be ported for each > >architecture? > > > > 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. 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. > 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..) _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
