Raspbian vs Wheezy (beta) Mono support

Poo. Back to square one then, bugging amazing mono coders into helping us!

This sounds like good news, and Jo Shields (mono maintainer in debian) calls mpthompson a "considerate soul"

http://lists.debian.org/debian-release/ ... 00385.html
First section about bug#682284, which this thread is all about.

I don't have an ETA on this work, as I'm finding it difficult to juggle "concentrating on crazy C and ARM assembly which is way over my head" and "fatherly duties for 10 week old baby" - I hope to at least have it compiling within a week, with actually working somewhere down the line, depending on how many relevant knowledgeable people I can corner.

Thank you, Jo Shields!

[mpthompson]

This sounds like good news, and Jo Shields (mono maintainer in debian) calls mpthompson a "considerate soul"

Who? Me?

I feel sorry for Jo Shields as I've been in that spot before (which involves a lot of swearing). Oh well, I'm sure once the fix is found he'll feel a lot better knowing the armhf stuff has been handled correctly. His report does sound promising.

Bug#682284: fixed in mono 2.10.8.1-6
has caused the Debian Bug report #682284,
regarding mono-runtime: SIGSEGV while executing native code on armhf
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

This sounds like good news, and Jo Shields (mono maintainer in debian) calls mpthompson a "considerate soul"

http://lists.debian.org/debian-release/ ... 00385.html
First section about bug#682284, which this thread is all about.

I don't have an ETA on this work, as I'm finding it difficult to juggle "concentrating on crazy C and ARM assembly which is way over my head" and "fatherly duties for 10 week old baby" - I hope to at least have it compiling within a week, with actually working somewhere down the line, depending on how many relevant knowledgeable people I can corner.

Thank you, Jo Shields!

Indeed, thank you very much Jo!

So it looks like the bug got "fixed", but not they way we would have liked it:

Changes:
mono (2.10.8.1-6) unstable; urgency=low
.
* [da2fc97] Remove armhf from list of supported architectures. It
ain't supported by the runtime in Mono 2.10.x, and trying to
shoehorn it in was more difficult than we had hoped. It will
return in the future, for Mono 2.12. (Closes: #682284)

Wait, so Oracle will support us but Xamarin won't (for this release)?

When is 2.12 coming out? I can't find any concrete days on the Mono website. As it supports Async/Await and that's not even out yet (c# 4.5 is in visual studio 11/windows 8 AFAIK) I'm guessing that's a blumming long way off.

This is depressing news.

Wait, so Oracle will support us but Xamarin won't (for this release)?

Has anyone actually reported the bug to Xamarin? The above mention was the Debian team that choose not to fix the issue.

I've tweeted and emailed, no luck so far.

I've tweeted and emailed, no luck so far.

Submitted issue to their bugzilla?
https://bugzilla.xamarin.com

If no one has then I could install Raspbian and compile an sample and file a report.

One solution would be to just buy a few Raspberries and send them to Xamarin HQ for da fellas to play with:) When dealing with "free" software one should go easy with demands or bad attitude, it's a bad motivator to get people to spend their spare time fixing issues for free. Check if any work can be done making the fixers life easier.

I'll bite... made offer, we'll see.

I'll bite... made offer, we'll see.

Response I got...
@jaebird I heard about it. Easy fix, switch to mono 2.11.3

I'm an old timer with Mono on x86 projects. It is easy to build and install a parallel Mono into /opt. I haven't done it in awhile, but if I have time, I'll post instructions/deps here.

I had a Xamarin guy sharing our office space this week because his home DSL was down. Irish corrosion (JCB through the fibre) apparently.

He heard our woes and posted a message up on the internal Xamarin IRC channel. Reply was "watch this space..." - appears that Xamarin are working on it, and they have a raspberry pi to play with. No timescale given.

[mpthompson]

Twinkletoes, thanks for the report. It would be nice if the Raspberry Pi started to help push solutions to problematic packages back upstream to Debian Wheezy armhf. Then the tail starts wagging the dog.

[plugwash]

I do try and push fixes back up to debian where appropriate. In this case though it sounds like debian will probablly get the fixes direct from upstream when the time comes.

[mpthompson]

Sorry, plugwash. I should have remembered you do indeed push fixes back upstream.

Good to hear there is some progress, I was getting downhearted. If we can get Xamarin on board, that would be amazing. I'm up for sending them bribes/free things, is there a fund I can pay into to help pay for the pis and gear to send them?

I'll bite... made offer, we'll see.

Response I got...
@jaebird I heard about it. Easy fix, switch to mono 2.11.3

I'm an old timer with Mono on x86 projects. It is easy to build and install a parallel Mono into /opt. I haven't done it in awhile, but if I have time, I'll post instructions/deps here.

Please do! I can't run Raspbian a the moment because of this issue, if there is a fix I will jump at the chance to try it.

I'll bite... made offer, we'll see.

Response I got...
I heard about it. Easy fix, switch to mono 2.11.3

I'm an old timer with Mono on x86 projects. It is easy to build and install a parallel Mono into /opt. I haven't done it in awhile, but if I have time, I'll post instructions/deps here.

Any tip to achieve this?

I am desperately trying to compile mono 2.11.4 on Raspbian Wheezy 2012-09-18 and all I get this error when I run make :

Error: selected processor does not support ARM mode 'dmb'

this changeset (https://github.com/mono/mono/commit/488 ... r/atomic.h) adds the dmb instruction to the mono code, however our processor does not support this instruction or the compiler is buggy. so maybe removing this instruction will work.

I've been investigating a bit further about the

Code: Select all

dmb

instruction error while compiling mono.
There is something not clear in the ARM instruction support..

The Raspberry Pi processor is a BCM2708
This a Broadcom implementation of ARM1176JZF-S
You can find the Technical Reference Manual here :
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf

This manual states that this processor implements the ARMv6 architecture with Thumb instructions. It also states that there is a pin indicating the state during a DMB (Data Memory Barrier)or DSB instruction.
The cat /proc/cpuinfo on the other hand returns :

Code: Select all

Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0004
Serial          : 0000000067d6523f

Which indicates a v6L (and not v61 as I've been reading previously), but CPU architecture 7

Anyway, the instruction set (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Cihedhif.html) seems to indicate that the instruction is not supported on v6 architectures.

The question is what's the purpose of the DMB pin if the instruction is not supported ?
But it seems it's actually not supported and the mono code should be reverted to previous version for the v6 architecture.

Hope it helps..

Is there any more news on this issue? I'm tecnically inept but I can help with raw man power if we need to get raise some more awareness. I hear the java issues are getting sorted out, I'd rather have parity with Oracle on this one!

Hi all,

I have installed the Arch image, and I am getting the same screen full of errors as the OP, with the addition of this at the top:

Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

I tried running locale-gen, but still no luck.

Isn't Mono supposed to run well on Arch?

Chris

Well I fixed the locale warning by editing /etc/locale.gen and then running locale-gen, but I still get the same screen full of errors as the OP.

OP here, Mono not supported on hard float, see up thread. The only way this will get fixed is upstream at Mono... Don't hold your breath...