Re: [Mono-dev] Mono Wizard
It depends on what kind of wizard Do you mean like Oz or Gandalf or Dumbledore? For Oz, you should try one of the brick roads - i think yellow. I am not sure happens with red. For Gandalf - You will need white - grey has been out of development for a while. Lastly, Dumbledore, after a major development effort and sacrifices, has been replaced with newer flavors like Potter, Granger and Weasley (and many more, see Hogwarts for details) Live long and may the source be with you. Hope this helps! On Tue, Mar 5, 2013 at 10:56 AM, ahdbk 3ah...@gmail.com wrote: hi , i whould like to develop a wizard using Mono Some indication ? best regards Ahd BEN KHEDER -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-Wizard-tp4658834.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and Clang
On Tue, Mar 5, 2013 at 3:35 PM, Alex Rønne Petersen a...@alexrp.com wrote: Hi list, Has anyone managed to build Mono with Clang? If so, do the resulting binaries pass the test suite? Thanks, Alex Fascinating. I did not know about clang until today. Apparently it is available on Ubuntu 12.04 as a deb package (v3.0, not 3.2). on mono 2.11.0: configure --with-tls=pthread CC=clang CXX=clang++ passes make passes make check most tests pass - one failure make run-test most tests pass for mscorlib - 67 not run and then I ran into a dependency problem (known and local to my test setup) and decided it is not worth investigating further. I am sure it is nothing. I think it is pretty stable. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Segmentation fault executing mono runtime tests on OpenIndiana
I am trying to get to the bottom of why some of the runtime tests fail on OpenIndiana (an OpenSolaris clone). Here is the information about the test that I am running, the standard output provided by mono -v, a stack trace and a snippet from the mono source file (v 2.11.4). https://gist.github.com/3890447 My assumption is that some code is jitted (line 148 in the C source file in the gist) It is executed (line 225 in the C source file in the gist) And it finally segfaults. Please let me know if I can provide any more details or diagnostic materials etc. Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on SMARTOS
On Tue, Oct 9, 2012 at 3:42 PM, Andres G. Aragoneses kno...@gmail.com wrote: On 09/10/12 14:53, Autif Khan wrote: On Tue, Oct 9, 2012 at 8:11 AM, Fatih Soydan [Personal] fatihsoy...@fatihsoydan.com wrote: Hi; Are there any pre compiled packages for smartos ? SmartOS seems to be catching fire :-) While there are no binaries, there are some tweaks needed to compile mono on SmartOS. Take a look at the following thread from a few weeks ago. http://lists.ximian.com/pipermail/mono-devel-list/2012-August/039520.html If you send a pull request with the change, it will most likely be merged to master so nobody needs tweaks or forks. Will do, I am still trying to get gcc to work on openindiana, will catch you (knocte) up on #mono-dev one of these days - once I am ready. Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on SMARTOS
On Tue, Oct 9, 2012 at 8:11 AM, Fatih Soydan [Personal] fatihsoy...@fatihsoydan.com wrote: Hi; Are there any pre compiled packages for smartos ? SmartOS seems to be catching fire :-) While there are no binaries, there are some tweaks needed to compile mono on SmartOS. Take a look at the following thread from a few weeks ago. http://lists.ximian.com/pipermail/mono-devel-list/2012-August/039520.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling mono? I give up [not proceeding] - if anything obvious i'm doing wrong let me know
On Mon, Apr 30, 2012 at 9:47 PM, Rob Wilkens robwilk...@gmail.com wrote: [apologies if duplicated - i sent from wrong account at first and don't think it went through] I hate trying to get other people's program's to build properly on a different computer than it was originally built on/for, but i gave building mono an honest effort before giving up. I've been trying different troubleshooting steps for something like 5 hours now; and that doesn't count changing any code, just building what was already written by others and trying existing programs with the output (in theory, if .net binaries are cross platform, you'd think the binaries on the same platform would be compatible with different builds of the runtime). No - thats not true. Only read further if you're interested in my struggle. I am basically writing this to say why i probably won't be able to debug this issue i earlier reported myself. Anyone know if i should file a bug report on that one? First, i tried building mono from the latest git source, but despite compiling and installing fine it gave me enough problems with compatibility with existing programs, that i just thought i'd try the same version i was already running on the system. Ok, So i'll get to where i'm at now: 1) I did an apt-get source mono ran an autogen, make. (and eventually make install) -- figuring this would get me the same version that i was running. 2) This built, or would build, version 2.10.8.1 -- in theory the same version i had installed. 3) libmonogc.la in libgc directory never built (and it was needed by other parts of the compile process.) There were no errors that i could tell; it just said something like LD libmonogc.la in the output from the makefile in that directory, and then continued on without actually building it. I half wonder if i'm missing something important to build it with. I actually had it echo the command line behind the 'LD' it was displaying, then tried strace/ltrace on it, but got lost following it and my frustration just led me to do the following: 4) I copied the two missing 'libgc' libraries (the binaries) from the git version which i earlier compiled Yes, i know it's not smart, but it got the whole thing to compile. I then did make install. 5) Afterwards: If I try to run monodevelop: -It gives me a few errors,they basically all say Mono.Addins version 0.6.0.0 is not found.. I googled it and saw that the current version is something like 0.6.2.0. I didn't bother redownloading it. -But it is there, if i remove my /usr/local version of the mono binaries, and run the same monodevelop, it runs If I try to run GhettoGtkAdmin.exe (the binary from the project i gave earlier): -Direct from the command line without 'mono' command: It works fine, but i suspect that this is using the /usr/bin version -If I run it with mono command (from /usr/local) i.e. 'mono GhettoGtkAdmin.exe', it complains that it can't load type 'MainWindow' which is one of the types in the program -- it's a System.TypeLoadException. -- but again, like monodevelop, if i remove the /usr/local version of the binaries for mono, it runs fine even with the 'mono' in the command line. I even ran a 'make check' in the mono source directory, and most (or many) of the tests passed -- at some point one of the check's failed to compile (the test source for Address.cs in versiontolerantserialization test was missing it said.) I tried running a build from apt-get source of libmono-addins, and i was going to rebuild monodevelop too, but i thought this was getting a little nuts. I realize i'm on my own with building from apt-get source, as these are ubuntu files and not mono project files. But i've put in enough time on this problem. I'm retired/disabled, i've got plenty of time, but there's a reason i'm disabled and it's not a physical disability. This is generating enough unneeded stress that i don't think this activity which i took on as a stress reliever is working out that way, it's more having the opposite effect. I swear i used to find programming to be one of those activities that relaxed me, i don't know if it's the illness, age, or years of being on disability (not working full time), but nowadays it just seems like more stress than it's worth for me. -Rob ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-compile mono to MIPS SOC w/CodeSourcery 3.93?
Hello---
I'm trying to cross-compile mono 2.10.2 from the source tarball. My build
machine is an x86 Linux PC running Fedora (could use one of the other
distros of that makes things easier). The target is a SOC with a vanilla
MIPS 24Kc core (little-endian, no FPU).
I found some instructions for ARM (http://mono-project.com/Mono%3aARM
http://stackoverflow.com/questions/4955314/cross-compile-mono-for-arm) which
I tried to adapt for MIPS, but have come up short. I'll spare the error
messages, but it dies in ./configure. I believe the root cause is not
setting the right combination of environment variables for confogure to
properly use the CodeSourcery 3.93 toolchain.
Specifically, I don't see (from looking at the output of ./configure --help)
how to override the default x86 headers and libraries, which would be needed
in addition to the compiler, linker, etc. Does anyone have more detailed
instructions on how I might accomplish this? I am not a newbie, but am
somewhat new to cross-compiling. The tutorial information I've been able to
find on automake, etc, is very general.
If I get enough hints to pull this off I'll be happy to write up a detailed
Wiki by way of compensation.
Thx in advance---
Maadmole
_prefix=mips-linux-gnu
export CC=$CSRC_ROOT/${_prefix}-gcc
export CXX=$CSRC_ROOT/${_prefix}-g++
export CPP=$CSRC_ROOT/${_prefix}-cpp
./configure --prefix=/usr/local --disable-mcs-build --host=mipsel
--enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs
--disable-mono-debugger
See of the following config options work for you.
I use them for my embedded mono (x86 and arm)
--disable-mcs-build mono_cv_uscore=no --with-tls=pthread
--with-sigaltstack=no --with-mcs-docs=no
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cross-compile mono to MIPS SOC w/CodeSourcery 3.93?
Hello---
I'm trying to cross-compile mono 2.10.2 from the source tarball. My build
machine is an x86 Linux PC running Fedora (could use one of the other
distros of that makes things easier). The target is a SOC with a vanilla
MIPS 24Kc core (little-endian, no FPU).
I found some instructions for ARM (http://mono-project.com/Mono%3aARM
http://stackoverflow.com/questions/4955314/cross-compile-mono-for-arm) which
I tried to adapt for MIPS, but have come up short. I'll spare the error
messages, but it dies in ./configure. I believe the root cause is not
setting the right combination of environment variables for confogure to
properly use the CodeSourcery 3.93 toolchain.
Specifically, I don't see (from looking at the output of ./configure --help)
how to override the default x86 headers and libraries, which would be needed
in addition to the compiler, linker, etc. Does anyone have more detailed
instructions on how I might accomplish this? I am not a newbie, but am
somewhat new to cross-compiling. The tutorial information I've been able to
find on automake, etc, is very general.
If I get enough hints to pull this off I'll be happy to write up a detailed
Wiki by way of compensation.
Thx in advance---
Maadmole
_prefix=mips-linux-gnu
export CC=$CSRC_ROOT/${_prefix}-gcc
export CXX=$CSRC_ROOT/${_prefix}-g++
export CPP=$CSRC_ROOT/${_prefix}-cpp
./configure --prefix=/usr/local --disable-mcs-build --host=mipsel
--enable-minimal=profiler,debug,logging,soft_debug --without-mcs-docs
--disable-mono-debugger
See of the following config options work for you.
I use them for my embedded mono (x86 and arm)
--disable-mcs-build mono_cv_uscore=no --with-tls=pthread
--with-sigaltstack=no --with-mcs-docs=no
Oh, I also had to apply a few patches - they are included below. The
last one will not be required for 2.10.11
--- mono-2.10.8.1.orig/Makefile.am 2012-01-25 14:24:43.564002232 -0500
+++ mono-2.10.8.1/Makefile.am 2012-01-25 14:25:02.036002218 -0500
@@ -4,10 +4,10 @@
MOONLIGHT_SUBDIRS = $(libgc_dir) eglib/src mono
if CROSS_COMPILING
-SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) data runtime
scripts man samples msvc $(docs_dir)
+SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) support data
runtime scripts man samples msvc $(docs_dir)
# Keep in sync with SUBDIRS
## 'tools' is not normally built
-DIST_SUBDIRS = po libgc eglib mono ikvm-native data runtime
scripts man samples tools msvc docs
+DIST_SUBDIRS = po libgc eglib mono ikvm-native support data runtime
scripts man samples tools msvc docs
else
if ONLY_MOONLIGHT
SUBDIRS = $(MOONLIGHT_SUBDIRS) runtime
--- mono-2.10.8.1.orig/data/config.in 2012-01-27 09:29:07.072001924 -0500
+++ mono-2.10.8.1/data/config.in2012-01-27 09:30:59.740001933 -0500
@@ -15,7 +15,7 @@
dllmap dll=i:msvcrt.dll target=@LIBC@ os=!windows/
dllmap dll=sqlite target=@SQLITE@ os=!windows/
dllmap dll=sqlite3 target=@SQLITE3@ os=!windows/
- dllmap dll=libX11 target=@X11@ os=!windows /
+ dllmap dll=libX11 target=libX11.so.6 os=!windows /
dllmap dll=libcairo-2.dll target=libcairo.so.2 os=!windows/
dllmap dll=libcairo-2.dll target=libcairo.2.dylib os=osx/
dllmap dll=libcups target=libcups.so.2 os=!windows/
--- mono-2.10.8.1.orig/mcs/class/Makefile 2012-01-27 16:20:36.319297999
-0500
+++ mono-2.10.8.1/mcs/class/Makefile2012-01-27 20:37:30.867593825 -0500
@@ -55,10 +55,8 @@
Novell.Directory.Ldap \
Mono.Security.Win32 \
System.DirectoryServices\
- RabbitMQ.Client \
Mono.Messaging \
System.Messaging\
- Mono.Messaging.RabbitMQ \
System.ServiceProcess \
System.Drawing.Design \
System.Design \
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Image.PropertyItems empty with mono
Hi, i'm porting a c# appliction to work with both .net and mono (for MacOS). The app should read an image and rotate it using the exif information for orientation. But when opening the image with mono it only gives me an empty PropertyItems array. I tried it with several mono versions starting from 2.6 until 2.10 but i have no idea what is missing. Any idea what i need to do in order to get the information from the image? Can you please include, as small as possible, code that you are using? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to combine Mono with Application Binaries for redistribution
I developed an applicaiton using MonoDevelop. It runs fine from the machine I developed on Chrome (OpenSUSE 11.4) with the related Mono products. I need my application to work on CentOS. I want to build a tar.gz or something similar that I can distribute to CentOS. Is there anyway to compile Mono with the source code I've developed to work within a self contained world. The only way my app would work on other Linux distro's is if they compile Mono from Source. Or is there another way to develop an application using Mono where you can package it to work on other Linux distros ? I am sure, I am missing something here, but 1) CentOS must have a mono package - why would your app not run with those binaries - unless 2) .. you changed mono's source, and distribute only binaries, that would be violating GPL or ... 3) your app is actually something that enhances mono So - what am I missing? Can you provide more details? Is it a .NET app or something in C/C++? Does it modify mono's sources? Are you open to open sourcing your app? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Newbie] Force to run a c# apps with Mono Runtime
On Sat, Feb 11, 2012 at 1:44 PM, Nixeus transfai...@free.fr wrote: Hello, I have an apps in c# designed for Mono. I don't have the source code, but just the EXE. I would like to force that this exe will be run with the MONO runtime. So in order to doignt this,i would like to create a c# apps that make a thing like this : System.Diagnostics.Process.start(MyExe.exe) but to force that my.exe.exe runs with the MONO Runtime. Nevertheless i would like to embedd the Mono Runtime in the application in order to execute the programm without having installing the MONO runtime. Is this possible ? How doing this please ? Thanks a lot for all your help, Best regards, Nixeus You can have the my.exe as an embedded resource in a C app - this C app could also have the mono runtime as embedded resource. It does look like an enorrmous task though. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libMonoPosixHelper and libMonoSupportW not being built when --disable-mcs-build
I am cross compiling mono and have success with it. The process as described is: 1) Compile mono on build/host machine for the libraries 2) Cross Compile mono with --disable-mcs-build and copy the .NET libraries to the target system. However, I have to use --disable-mcs-build mono_cv_uscore=no --with-tls=pthread --with-sigaltstack=no for configuration. Then I copy over both the etc/mono and usr/lib/mono directories to the target system At this point of time, I am able to get all the runtime tests to pass and almost all the mscorlib and System.dll tests to pass. The problem is that when I try to execute a .NET app that uses Windows Forms, I get a DllNotFoundException for these (unmanaged) libraries. I have verified that libMonoPosixHelper.* and libMonoSupportW.* are not being built, even when we just compile (not necessarily cross compile) mono with --disable-mcs-build So, whats going on what can I do to force build this? I am using the latest stable version 2.10.8.1 Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libMonoPosixHelper and libMonoSupportW not being built when --disable-mcs-build
I believe that support directory is intentionally being left out during cross compilation. I wonder why? Does anyone know? Excerpts from root Makefile.in - notice how support is missing when @CROSS_COMPILING_FALSE @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_FALSE@SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) support data runtime scripts man samples msvc $(docs_dir) @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_TRUE@SUBDIRS = $(MOONLIGHT_SUBDIRS) runtime @CROSS_COMPILING_TRUE@SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) data runtime scripts man samples msvc $(docs_dir) # Keep in sync with SUBDIRS @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_FALSE@DIST_SUBDIRS = po libgc eglib mono ikvm-native support data runtime scripts man samples tools msvc docs # Keep in sync with SUBDIRS @CROSS_COMPILING_TRUE@DIST_SUBDIRS = po libgc eglib mono ikvm-native data runtime scripts man samples tools msvc docs On Wed, Jan 25, 2012 at 11:19 AM, autif khan autif.ml...@gmail.com wrote: I am cross compiling mono and have success with it. The process as described is: 1) Compile mono on build/host machine for the libraries 2) Cross Compile mono with --disable-mcs-build and copy the .NET libraries to the target system. However, I have to use --disable-mcs-build mono_cv_uscore=no --with-tls=pthread --with-sigaltstack=no for configuration. Then I copy over both the etc/mono and usr/lib/mono directories to the target system At this point of time, I am able to get all the runtime tests to pass and almost all the mscorlib and System.dll tests to pass. The problem is that when I try to execute a .NET app that uses Windows Forms, I get a DllNotFoundException for these (unmanaged) libraries. I have verified that libMonoPosixHelper.* and libMonoSupportW.* are not being built, even when we just compile (not necessarily cross compile) mono with --disable-mcs-build So, whats going on what can I do to force build this? I am using the latest stable version 2.10.8.1 Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libMonoPosixHelper and libMonoSupportW not being built when --disable-mcs-build
I looked thru git to see how this evolved. It lead me to commit 9c48ce0cec7f37fd9f90be75cf7887d014048b25 by Gonzalo. I was hoping he could shed some light on this. I just dont want this to bite me down the road. On Wed, Jan 25, 2012 at 12:59 PM, autif khan autif.ml...@gmail.com wrote: I believe that support directory is intentionally being left out during cross compilation. I wonder why? Does anyone know? Excerpts from root Makefile.in - notice how support is missing when @CROSS_COMPILING_FALSE @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_FALSE@SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) support data runtime scripts man samples msvc $(docs_dir) @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_TRUE@SUBDIRS = $(MOONLIGHT_SUBDIRS) runtime @CROSS_COMPILING_TRUE@SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) data runtime scripts man samples msvc $(docs_dir) # Keep in sync with SUBDIRS @CROSS_COMPILING_FALSE@@ONLY_MOONLIGHT_FALSE@DIST_SUBDIRS = po libgc eglib mono ikvm-native support data runtime scripts man samples tools msvc docs # Keep in sync with SUBDIRS @CROSS_COMPILING_TRUE@DIST_SUBDIRS = po libgc eglib mono ikvm-native data runtime scripts man samples tools msvc docs On Wed, Jan 25, 2012 at 11:19 AM, autif khan autif.ml...@gmail.com wrote: I am cross compiling mono and have success with it. The process as described is: 1) Compile mono on build/host machine for the libraries 2) Cross Compile mono with --disable-mcs-build and copy the .NET libraries to the target system. However, I have to use --disable-mcs-build mono_cv_uscore=no --with-tls=pthread --with-sigaltstack=no for configuration. Then I copy over both the etc/mono and usr/lib/mono directories to the target system At this point of time, I am able to get all the runtime tests to pass and almost all the mscorlib and System.dll tests to pass. The problem is that when I try to execute a .NET app that uses Windows Forms, I get a DllNotFoundException for these (unmanaged) libraries. I have verified that libMonoPosixHelper.* and libMonoSupportW.* are not being built, even when we just compile (not necessarily cross compile) mono with --disable-mcs-build So, whats going on what can I do to force build this? I am using the latest stable version 2.10.8.1 Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to access AOTed assembly code?
Kamal,
Can you please include the following:
1) which gcc
2) output of gcc --version
3) gcc helloworld.c - and then the output of file a.out (just have
main(){printf(HW\n;)} in helloworld.c
These will eliminate cross compiler as an issue.
4) The full command that is executed before you get this output - it
is above this output
On Wed, Jan 25, 2012 at 3:45 PM, Kamal Aboul-Hosn ka...@sooloos.com wrote:
Thanks, Robert, that worked very well. I have one more question, if I may. So
I'm embedding Mono on Android on ARM. Up until now, I've been AOT compiling
the libraries by running a little app on the Android device itself.
Obviously, in the long term, this is not really a good option. So now, I'm
trying to build a Mono cross compiler for Android ARM on my Mac OS X machine
(gcc --arch returns i686-apple-darwin11-llvm-gcc-4.2 if that is useful).
I do the following configure:
./configure --target=armv5-linux-androideabi --enable-nls=no
--prefix=/Users/kamal/mono-cross --disable-mcs-build
I also have the CC environment variable and CXX environment variable set to
gcc -m32 and g++ -m32, respectively, as I believe I read that the cross
compiler cannot work if built for 64-bit. Whenever I run make, I quickly get
the following errors:
mach-support-arm.c: In function ‘mono_mach_arch_get_ip’:
mach-support-arm.c:24: error: ‘arm_thread_state_t’ undeclared (first use in
this function)
mach-support-arm.c:24: error: (Each undeclared identifier is reported only
once
mach-support-arm.c:24: error: for each function it appears in.)
mach-support-arm.c:24: error: ‘arch_state’ undeclared (first use in this
function)
mach-support-arm.c:24: error: expected expression before ‘)’ token
mach-support-arm.c:27: warning: control reaches end of non-void function
mach-support-arm.c: In function ‘mono_mach_arch_get_sp’:
mach-support-arm.c:32: error: ‘arm_thread_state_t’ undeclared (first use in
this function)
mach-support-arm.c:32: error: ‘arch_state’ undeclared (first use in this
function)
mach-support-arm.c:32: error: expected expression before ‘)’ token
mach-support-arm.c:35: warning: control reaches end of non-void function
mach-support-arm.c: In function ‘mono_mach_arch_get_mcontext_size’:
mach-support-arm.c:40: error: invalid application of ‘sizeof’ to incomplete
type ‘struct __darwin_mcontext’
mach-support-arm.c: In function ‘mono_mach_arch_thread_state_to_mcontext’:
mach-support-arm.c:46: error: ‘arm_thread_state_t’ undeclared (first use in
this function)
mach-support-arm.c:46: error: ‘arch_state’ undeclared (first use in this
function)
mach-support-arm.c:46: error: expected expression before ‘)’ token
mach-support-arm.c:49: error: dereferencing pointer to incomplete type
mach-support-arm.c: In function ‘mono_mach_arch_get_thread_state_size’:
mach-support-arm.c:55: error: ‘arm_thread_state_t’ undeclared (first use in
this function)
mach-support-arm.c:56: warning: control reaches end of non-void function
mach-support-arm.c: In function ‘mono_mach_arch_get_thread_state’:
mach-support-arm.c:61: error: ‘arm_thread_state_t’ undeclared (first use in
this function)
mach-support-arm.c:61: error: ‘arch_state’ undeclared (first use in this
function)
mach-support-arm.c:61: error: expected expression before ‘)’ token
mach-support-arm.c:64: error: ‘ARM_THREAD_STATE_COUNT’ undeclared (first use
in this function)
make[4]: *** [mach-support-arm.lo] Error 1
Does anyone know how to overcome these errors?
Much appreciated!
Kamal
On Jan 24, 2012, at 4:08 PM, Robert Jordan wrote:
On 24.01.2012 19:39, Kamal Aboul-Hosn wrote:
Hi, everyone,
If I call mono --aot=static,asmonly on a dll to generate a .s file,
how can I get Mono to load the generated AOT'ed assembly if I include
the .s in a native .so I'm building myself as part of an application?
It seems Mono normally just goes looking for a .so file for the
AOT'ed code. Is it possible to get Mono to use the linked in AOT'ed
code in the same native library as the rest of my application? Please
let me know if I can provide any more details.
First, you must embed the runtime as described here:
http://mono-project.com/Embedding_Mono
Second, you must register the static AOT assembly with
mono_aot_register_module. See the description of
--aot=static on mono's man page.
This assembly can be consumed like any other file-based
assembly using the embedding API.
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libtool version mismatch
I have been working on writing a recipe for mono for open embedded (OE). I have successfully written one for lbgdiplus and am making headway with mono. Mono comes with libtool version 2.2.6, OE uses 2.4 After ./configure, when make is being executed, I am getting the following error for the following command: Command: /bin/sh ./libtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/home/autif/data2/nosync/dev/yocto/kokosdk/tmp/sysroots/crownbay -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\hans_bo...@hp.com\ -DPACKAGE_URL=\\ -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DPARALLEL_MARK=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -O2 -pipe -g -feliminate-unused-debug-types -g -mno-tls-direct-seg-refs -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c Error: | libtool: Version mismatch error. This is libtool 2.4, but the | libtool: definition of this LT_INIT comes from libtool 2.2.6. | libtool: You should recreate aclocal.m4 with macros from libtool 2.4 | libtool: and run autoconf again. | make[3]: *** [allchblk.lo] Error 63 Here is how LT_INIT is defined in aclocal.m4: # LT_INIT([OPTIONS]) # -- AC_DEFUN([LT_INIT], [AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT AC_BEFORE([$0], [LT_LANG])dnl AC_BEFORE([$0], [LT_OUTPUT])dnl AC_BEFORE([$0], [LTDL_INIT])dnl m4_require([_LT_CHECK_BUILDDIR])dnl dnl Autoconf doesn't catch unexpanded LT_ macros by default: m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl m4_pattern_allow([^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$])dnl dnl aclocal doesn't pull ltoptions.m4, ltsugar.m4, or ltversion.m4 dnl unless we require an AC_DEFUNed macro: AC_REQUIRE([LTOPTIONS_VERSION])dnl AC_REQUIRE([LTSUGAR_VERSION])dnl AC_REQUIRE([LTVERSION_VERSION])dnl AC_REQUIRE([LTOBSOLETE_VERSION])dnl m4_require([_LT_PROG_LTMAIN])dnl dnl Parse OPTIONS _LT_SET_OPTIONS([$0], [$1]) # This can be used to rebuild libtool when needed LIBTOOL_DEPS=$ltmain # Always use our own libtool. LIBTOOL='$(SHELL) $(top_builddir)/libtool' AC_SUBST(LIBTOOL)dnl _LT_SETUP # Only expand once: m4_define([LT_INIT]) ])# LT_INIT What changes should be made to the auto tools files to fix this? PS - by no means am I suggesting that mono should upgrade to libtool 2.4, I want to make these changes and submit a patch to OE that goes along with the recipe. Thanks! Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cross compilation issue
I am trying to cross compile mono with success. However, there is a step that I am not able to figure out. The steps are as follows: 1) Compile mono for the host system - to save the mcs for later use 2) Cross Compile mono with --disable-mcs-build 3) Copy mcs directory from 1 into 2 4) Profit I am having problems ins step 2. To elaborate: 2.1) ./configure --disable-mcs-build 2.2) rm libtool 2.3) cp /path/to/cross/libtool . 2.4) make This works just fine ... except: When the compilation reaches mono/mini directory, I fail ../../doltlibtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse -c -o mdb-debug-info32.lo ../../../../../xumono/mono-2.6.3/mono/mini/mdb-debug-info32.s libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[4]: *** [mdb-debug-info32.lo] Error 1 make[4]: Leaving directory `/home/autif/data2/nosync/dev/yocto/apps/mono/2.6.3/build/mono/mini' If I manually go into the mono/mini directory and execute the following command: ../../doltlibtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse -c -o mdb-debug-info32.lo ../../../../../xumono/mono-2.6.3/mono/mini/mdb-debug-info32.s --tag=CC it compiles just fine. If I go back to the build directory and re-run make, also everything compiles just fine and the build completes. I am using mono version 2.6.3 (for a number of reasons, 2.10.8.1 does not even begin to compile because of toolchain issues being the first). My guess is that --tag=CC is missing somewhere in Makefile.am or Makefile.in in mono/mini - If someone can point me to it, I would be grateful. Thanks Autif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
