hello,
i have just subscribed to that list in order to help advancing
in my mono based duties and for helping mono people in their targets.
my setup:
at present i am having an ARM Cortex-A8 (TI OMAP3) based portable system as my
development target. most of the compilation is based on an x86 Linux
On 06.08.2010 12:40, Alexander Stohr wrote:
> problem:
> right now i am using the daily snapshot of mono dated 2010-08-02 in a custom
> bitbake setup (made this work on my own) for cross compilation using this set
> of switches:
> EXTRA_OECONF_arm += " --disable-mcs-build --with-mcs-docs=no --wit
hello robert,
thanks for your quick response.
right now i am not absolutely sure if the corner stones of my build setup were
taken into consideration. i was...
* doing a *cross* build (using a bunch of options to make it work; FPU setting
probably too conservative)
* installing tools and libs b
snippet of mono daily 2010-08-02 from a "make -i check" on my target:
make all-local
/bin/sh ./../../../mkinstalldirs ../../../class/lib/net_4_0/
mkdir -p -- ../../../class/lib/net_4_0/
mkdir: cannot create directory `../../../class/lib/net_4_0/': File exists
touch ../../../class/lib/net_4_0//.sta
I'm using Mono 2.6.7/MS .NET 3.5SP1
I have a serialization problem trying to make Mono WCF interact with MS WCF.
The service is defined as the following:
[OperationContract]
ServiceResult TestMethod(string varA, int varB);
where ServiceResult is a generic class for returning results, so
running a custom application on Linux (ARM Cortex-A8)
exposed me repeated stability problems. somteimes it
happens in between the first few seconds, other times
it takes much longer. (with a second binary build for x86
the application was run as well but seemed to work fine.)
i am using the OpenEmb
Hi,
-
> in the debug case i can see things like this:
>
> Unhandled Exception: System.TypeInitializationException: An exception was
> thrown by the type initializer for System.Windows.Forms.XplatUI --->
> System.ArgumentOutOfRangeException: l
> oad facto
i dont know what sort of floating point feature the tested application is using
but the configuration line for the mono cross compile looks like that:
EXTRA_OECONF_arm += " --disable-mcs-build --with-mcs-docs=no --with-sgen
--enable-small-config --with-tls=pthread --with-sigaltstack=no
CFLAGS=-
Hi,
Try -DARM_FPU_VFP.
Zoltan
On Fri, Aug 6, 2010 at 4:56 PM, Alexander Stohr wrote:
> i dont know what sort of floating point feature the tested application is
> using but the configuration line for the mono cross compile looks like that:
>
> EXTRA_OECONF_arm += " --disable-mcs-
On Thu, Aug 5, 2010 at 8:37 PM, Jb Evain wrote:
> I'll give my patch a try with an mkbundled application.
Yep, my patch works for this scenario. I'll commit it to master.
--
Jb Evain
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
thanks Zoltan, the changed FPU setting made that early abort vanish when that
commandline switch is enabled. at least now i am getting bombarded with an
insane amount of prints per second at that layer. ;-)
i am still wondering why no-FPU is a no-go for that ARM platform as i expected
the mono
9,99 ¿/mtl.!*
http://portal.gmx.net/de/go/dsl
diff -rusb mono-20100806.orig/eglib/src/goutput.c mono-20100806/eglib/src/goutput.c
--- mono-20100806.orig/eglib/src/goutput.c 2010-05-02 09:01:29.0 +0200
+++ mono-20100806/eglib/src/goutput.c 2010-08-06 17:42:07.0 +0200
@@ -151,7 +1
Hello Alexander,
I like the patch, but it would be best if you included ChangeLog
entries that detail the changes.
> found a location in fatal error area where compiler complained about a
> function returning whilst it should not return. in fact it was dependent on a
> variable that could b
> I see that in the below files there is "Status s;" or "Status status;".
> Status is declared in Xlib.h as an int.
> But on those contexts it should be GpStatus and not Status.
> GpStatus is an enum so using Status compiles anyway.
> But I think GpStatus is more correct.
Good point; I have mad
14 matches
Mail list logo
