Has anyone tried to port Mono to RTEMS

Fri Jul 21 02:42:51 UTC 2017

On Thu, Jul 20, 2017 at 7:07 PM, xuelin.tian at qkmtech.com <
xuelin.tian at qkmtech.com> wrote:

> I just followed the instructions from Mono, and did some changes obviously.
> I did not use ScratchBox to cross-compile my Mono on ARM, just use
> arm-rtems4.11-gcc to cross-compile it. Is that right?
> Do I need to modify the source code from Mono to port to RTEMS?
>
Some context you really should provide:
- What platform are you building on?
- Where did you get the source files? (if git, are you building head? I
have had many problems building mono from head)
- Without posting your complete build output there is no way to tell what
is happening.

This is just a shot in the dark, but did you google Time Zone variable?
Google says you need to set a TZ environment variable.

Russ

> ------------------------------
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> *From:* Russell Haley <russ.haley at gmail.com>
> *Date:* 2017-07-21 00:16
> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
> <joel at rtems.org>
> *CC:* users <users at rtems.org>
> *Subject:* Re: Has anyone tried to port Mono to RTEMS
> Did you get it to build natively?‎ What is your host. Build output would
> be helpful.
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
> *From: *xuelin.tian at qkmtech.com
> *Sent: *Thursday, July 20, 2017 5:53 AM
> *To: *Russell Haley; Joel Sherrill
> *Cc: *users at rtems.org
> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>
> I have been struck by it for like 2 days.
> I want to cross-compile Mono for a test, and I enter:
>
>
> *./autogen.sh --prefix=/opt/Mono/mono-4.8.1.0/mono-arm --target=arm-rtems4.11 --host=x86_64-unknown-linux CC=/opt/rtems-4.11.1-release/4.11-tools/bin/arm-rtems4.11-gcc CFLAGS="-qrtems -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/lib -B/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/ -I//opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib/include --specs bsp_specs -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9"*
>
> It goes well at first, then the error came up:
>
>
> *checking for timezone variable... noconfigure: error: unable to find a way to determine timezone*
>
> I can not really understand the content from config.log
>
> Can anyone help me with this? Thanks a lot
>
> ------------------------------
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> *From:* Russell Haley <russ.haley at gmail.com>
> *Date:* 2017-07-14 12:44
> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
> <joel at rtems.org>
> *CC:* users <users at rtems.org>
> *Subject:* Re: Has anyone tried to port Mono to RTEMS
> Thinking about it, Lua is designed to be statically linked into C
> applications and your scripts are loaded and executed by your application
> at runtime. This is how lua is plugged into many video games like world or
> warcraft and roblox.
>
> From my simplistic understanding of rtems (and everything I just said),
> that would be the way you would statically link lua into rtems?
>
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
> *From: *xuelin.tian at qkmtech.com
> *Sent: *Thursday, July 13, 2017 9:03 PM
> *To: *Russell Haley; Joel Sherrill
> *Cc: *users at rtems.org
> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>
> OK, thanks a lot.
> I will go through Lua today, to see if there is something interesting
> there.
>
> ------------------------------
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> *From:* Russell Haley <russ.haley at gmail.com>
> *Date:* 2017-07-14 11:57
> *To:* xuelin.tian <xuelin.tian at qkmtech.com>; Joel Sherrill
> <joel at rtems.org>
> *CC:* users <users at rtems.org>
> *Subject:* Re: Has anyone tried to port Mono to RTEMS
> Just my opinion on the 'or other vm' comment.
>
> If your requirement is not strictly mono, I highly suggest something small
> and simple like Lua. It's a a very efficient vm and is cross compatible
> with all major platforms. The only requirement for Lua is c99.
>
> The language is very simple and bare bones. You pick your tools from git
> or a repository manager called luarocks (luarocks.org). That's where the
> 'hard part' of Lua comes in. It's very hands on because you need to find or
> write almost everything you need.
>
> I am putting together a 'lightweight' IoT platform using Lua 5.3 and a
> very sophisticated polling library called cqueues. There is an http library
> called lua-http based on cqueues that contains a client and server
> implementation of most major http standards including http2 and websockets.
> The requirements for cqueues are a polling library such as epoll or kqueues
> (or even poll or select). I'm not sure how well that would plug into rtems.
> ‎At this point I'm cross compatible for most major Nixs' though.
>
> Nonetheless, the overhead of mono is not really worth it if you are doing
> simple things. ‎That's why I switched away from DotNet for my project. If
> you have code to port, or have DotNet developers, mono makes sense.
>
> ‎Just my opinion.
>
> HTH
> Russ
>
> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
> *From: *xuelin.tian at qkmtech.com
> *Sent: *Thursday, July 13, 2017 8:38 PM
> *To: *Joel Sherrill; Russell Haley
> *Cc: *users at rtems.org
> *Subject: *Re: Re: Has anyone tried to port Mono to RTEMS
>
> Yes, I am trying to build it from source according to Russell.
>
> As to .net core, I may not have a deep understanding of it. I think for
> now, Mono may be the best choice for me, since I need to make it (porting
> Mono or other VM to rtems) work in a few days.
>
> ------------------------------
> Best wishes,
> xuelin.tian at qkmtech.com
>
>
> *From:* Joel Sherrill <joel at rtems.org>
> *Date:* 2017-07-13 01:08
> *To:* Russell Haley <russ.haley at gmail.com>
> *CC:* xuelin.tian at qkmtech.com; users at rtems.org
> *Subject:* Re: Re: Has anyone tried to port Mono to RTEMS
> The reply from Russell is very good advice. Look forward when porting and
> make sure you are porting something with a future.
>
> For Mono, I did exactly what he outlined. I built native. I recall it
> using a
> fairly normal configure script and I just added --target=XXX-rtems. I might
> have added some CFLAGS but don't recall.
>
> I focused on the run-time interpreter and ignored the JIT. The run-time
> translated Mono calls into C library and POSIX calls. If there was a
> compilation issue, I tried to fix it where ever it had to be fixed. Always
> being
> open to adding something to either RTEMS or newlib if possible
> and needed.
>
> --joel
>
> On Wed, Jul 12, 2017 at 11:03 AM, Russell Haley <russ.haley at gmail.com>
> wrote:
>
>> On Tue, Jul 11, 2017 at 9:31 PM, xuelin.tian at qkmtech.com
>> <xuelin.tian at qkmtech.com> wrote:
>> > Dear Joel,
>> > Recently, I continue to port Mono to RTEMS.
>> > Porting consists of two parts, according to the Mono documents online,
>> JIT
>> > engine and OS support.
>> > JIT part is already done, since I use ARM platform.
>> > And I am confuesd about OS part and how to build Mono on RTEMS.
>> > Could you recall any details about how to build Mono on RTEMS? Thank
>> you.
>>
>> I'm not sure that's quite right. There are really 3 parts: The
>> application framework, the 'JIT' (Mono Runtime, or Common Language
>> Runtime in Microsoft .Net) and the OS specific layer. The application
>> framework and the JIT are common to all platforms. The OS specific
>> parts are in the Mono Runtime where it translates the Interediate
>> Language (IL) to machine specific code at ... er ... runtime. The Mono
>> Runtime is being slowly replaced by the Roslyn compiler, which is open
>> source from Microsoft (very very cool stuff).
>>
>> Building Mono requires a number of parts, including boot strapping the
>> build and downloading binaries from nuget (last time I did it,
>> anyway). I've never attempted to cross compile Mono. I would assume
>> you would change the make file to point to a cross compiler such as
>> arm-unknown-gcc (not sure about the RTEMS specifics).
>>
>> In my opinion the best bet is to pull the mono repository from GitHub
>> and build it for your host platform first. Then you could look at
>> modifying it to build on arm.
>>
>> That said, Mono is a dead/dying platform. Microsoft has bought
>> Xamarian (Mono sponsor company). Now the Mono Dev Team is slowly
>> porting everything over to the Microsoft .Net Core code. Once the
>> majority of libraries are converted, they can then write Mono specific
>> modules for legacy applications and then shuffle everyone over to
>> DotNet Core. It might be wise to look at using the DotNet Core instead
>> of Mono. There are a number of reasons to prefer the DotNet Core:
>>
>> - Designed to be small and use a package manager to import required
>> external libraries. This was done with embedded systems in mind.
>> - Better interpreter: the new interpreters (Rosylin and the other that
>> I don't remember the name of) are very efficient compared to the Mono
>> mc.
>> - More efficient runtime. The Mono Runtime is known to be slow.
>>
>>  Here would be a good place to start with the DotNet Core as they have
>> nightly arm builds.
>>
>> https://stevedesmond.ca/blog/net-core-on-arm
>>
>>
>> HTH,
>>
>> Russ
>>
>> > ________________________________
>> > Best wishes,
>> > xuelin.tian at qkmtech.com
>> >
>> >
>> > From: Joel Sherrill
>> > Date: 2017-05-24 20:19
>> > To: xuelin.tian
>> > CC: rtems-users at rtems.org
>> > Subject: Re: Has anyone tried to port Mono to RTEMS
>> >
>> >
>> > On May 23, 2017 8:58 PM, "xuelin.tian at qkmtech.com" <
>> xuelin.tian at qkmtech.com>
>> > wrote:
>> >
>> > Dear all,
>> > Is that possible to port Mono to RTEMS? Has anyone tried this before?
>> > As I notice that there is an open project in RTEMS projects.
>> >
>> >
>> > Sometime ago, I was asked to provide an estimate for this. It had to be
>> > between five and ten years ago because we were at the old office but
>> after
>> > we had done a few years of GSoC. I did enough work preparing the
>> estimate
>> > where I had the code building without too much effort. I saw the
>> challenge
>> > as getting the test suite running since you would have to create a test
>> > harness and build/assembly helper that packaged the interpreted code
>> with
>> > the interpreter in order to run it. At that time, I envisioned having to
>> > create a base image and a filesystem image per test.
>> >
>> > Our POSIX was good enough then to avoid much trouble. It should only be
>> > easier now since the POSIX support has improved.
>> >
>> > There were a lot of Mono tests and I expected most to pass quickly. But
>> > there was no way to know how many issues would be encountered and how
>> many
>> > root causes there would be. I expected to fix one or two things and
>> then run
>> > all the tests. That was where I expected time to be consumed.
>> >
>> > FWIW I recall the GSoC date part because they thought we could
>> magically get
>> > students to do testing for free on a schedule. :)
>> >
>> > I hope that helps. It is feasible but the key is testing.
>> >
>> > --joel
>> >
>> >
>> > ________________________________
>> > Best wishes,
>> > xuelin.tian at qkmtech.com
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/users
>> >
>> >
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/users
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170720/9a220b16/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Catch(07-21-10-02-46).jpg
Type: image/jpeg
Size: 56875 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20170720/9a220b16/attachment-0002.jpg>