Re: [Mono-dev] building mono on OpenSolaris x86_64
To continue my story I have disabled dtrace, that is, I have used the following: CC=x86_64-pc-solaris2.11-gcc CXX=x86_64-pc-solaris2.11-g++ \ CFLAGS=-I/opt/mono/include LDFLAGS=-m64 -L/opt/mono/lib -R/opt/mono/lib \ ./configure --with-gc=boehm --prefix=/opt/mono --enable-big-arrays --disable-dtrace But now compilation stops with the following error message: make[6]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' *** The compiler 'gmcs' doesn't appear to be usable. *** Trying the 'monolite' directory. make[7]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' make[8]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' * Assertion at mini-exceptions.c:1835, condition `staddr' not met It is true that gmcs.exe is nowhere in the source tree but there is ./mcs/class/lib/monolite/mcs.exe which is not usable either. Any suggestions? A.S. -- Apostols Syropoulos Xanthi, Greece ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] building mono on OpenSolaris x86_64
On 07.03.2011 15:45, Απόστολος Συρόπουλος wrote: To continue my story I have disabled dtrace, that is, I have used the following: CC=x86_64-pc-solaris2.11-gcc CXX=x86_64-pc-solaris2.11-g++ \ CFLAGS=-I/opt/mono/include LDFLAGS=-m64 -L/opt/mono/lib -R/opt/mono/lib \ ./configure --with-gc=boehm --prefix=/opt/mono --enable-big-arrays --disable-dtrace But now compilation stops with the following error message: make[6]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' *** The compiler 'gmcs' doesn't appear to be usable. *** Trying the 'monolite' directory. make[7]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' make[8]: Entering directory `/container/mono/latest/mono-2.10.1/mcs' * Assertion at mini-exceptions.c:1835, condition `staddr' not met Try to configure with --with-sigaltstack=no and remove --enable-big-arrays. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] How to generate definitions for MoMA
Hi Guys, I am trying to run MoMA tool against a custom build of mono framework. I already have the framework binaries built and now as I understand I need to produce the definition files. Is there any information about this? Right now I am looking the source code: https://github.com/mono/moma and hopefully will figure it out, but any guidance is appreciated as I need to finish it until Monday (evening, but in USA its morning). -- View this message in context: http://mono.1490590.n4.nabble.com/How-to-generate-definitions-for-MoMA-tp3337693p3337693.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-dev] PDB native support in C from C# open source project
Hello, Ref :- http://www.mono-project.com/StudentProjects#Native_support_for_PDB I'd be interested in contributing in this area, is it still an open item ? thanks David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] building mono on OpenSolaris x86_64
Try to configure with --with-sigaltstack=no and remove --enable-big-arrays. Indeed with these options mono compiled just fine. Thank you. A.S. -- Apostols Syropoulos Xanthi, Greece ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.10.1 Can't open a Windows Form on Windows 7 x64
Hi Guy, The bug reporting page is here: http://mono-project.com/Bugs This looks like the problem I ran into, since I was crashing on that same line. I submitted a patch to this list on 2/28. My post got no response, but hopefully someone with commit access will apply it to the official sources. Regards, Mark On 3/5/2011 2:07 AM, Guy Sherman wrote: Hi, I’ve been working on embedding mono in a sandbox game engine I’m working on. I’m running 64bit Windows 7, and I’ve built v2.10.1 of the mono runtime for 64bit, and it seems to have worked…mostly. I had 2.6.7 working quite well (64-bit, Windows 7, vs2010), loading up a windows form, which then made an internal call (using the mono api for adding functions into the runtime) which attached a DirectX renderer to it, and all was happy. I then wanted some .net 4 features like Xaml and WPF, so I upgraded to 2.10.1, was very pleased with how much easier the build was (only a little bit of mucking about needed to get the 64it build working) but have run into a problem. It seems that any code that creates a windows form crashes the runtime. To make sure it wasn’t my code, I created a simple WindowsFormsApplication1, and ran it first with the Win32 mono.exe that came with the 2.10.1 install – fine. I then ran it with my 64-bit build of mono.exe and it failed – first time I ran I got a crashdump, now it just quits me back to the console window, and I can’t find the crashdump files. This is a standard System.Windows.Form, not a WPF window. I can, however, tell you where it fails in the mono runtime code because I can debug up to it in my embedding host. Unhandled exception at 0x07fee20b8065 (mono-2.0.dll) in SuperNova.exe: 0xC005: Access violation reading location 0x00020037. Mono\metadata\class.c:4681 : if (class-parent !class-parent-inited) I have saved a memory dump out of visual studio, but it is 71mb so I’ve nowhere to put it – let me know if you want it. I’m ok to go back to my builds of 2.6.7 for now – I don’t NEED the .net 4 stuff for the moment. If there is a more official place to log this can someone let me know, I’ll be happy to do it. Thanks, Guy Sherman web: http://www.guysherman.com This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.10.1 Can't open a Windows Form on Windows 7 x64
Mark, I will look into your patch shortly. Thanks for tracking it down. Thanks, Jonathan On Mon, Mar 7, 2011 at 12:28 PM, Mark Sciabica msciab...@itracs.com wrote: Hi Guy, The bug reporting page is here: http://mono-project.com/Bugs This looks like the problem I ran into, since I was crashing on that same line. I submitted a patch to this list on 2/28. My post got no response, but hopefully someone with commit access will apply it to the official sources. Regards, Mark On 3/5/2011 2:07 AM, Guy Sherman wrote: Hi, I’ve been working on embedding mono in a sandbox game engine I’m working on. I’m running 64bit Windows 7, and I’ve built v2.10.1 of the mono runtime for 64bit, and it seems to have worked…mostly. I had 2.6.7 working quite well (64-bit, Windows 7, vs2010), loading up a windows form, which then made an internal call (using the mono api for adding functions into the runtime) which attached a DirectX renderer to it, and all was happy. I then wanted some .net 4 features like Xaml and WPF, so I upgraded to 2.10.1, was very pleased with how much easier the build was (only a little bit of mucking about needed to get the 64it build working) but have run into a problem. It seems that any code that creates a windows form crashes the runtime. To make sure it wasn’t my code, I created a simple WindowsFormsApplication1, and ran it first with the Win32 mono.exe that came with the 2.10.1 install – fine. I then ran it with my 64-bit build of mono.exe and it failed – first time I ran I got a crashdump, now it just quits me back to the console window, and I can’t find the crashdump files. This is a standard System.Windows.Form, not a WPF window. I can, however, tell you where it fails in the mono runtime code because I can debug up to it in my embedding host. Unhandled exception at 0x07fee20b8065 (mono-2.0.dll) in SuperNova.exe: 0xC005: Access violation reading location 0x00020037. Mono\metadata\class.c:4681 : if (class-parent !class-parent-inited) I have saved a memory dump out of visual studio, but it is 71mb so I’ve nowhere to put it – let me know if you want it. I’m ok to go back to my builds of 2.6.7 for now – I don’t NEED the .net 4 stuff for the moment. If there is a more official place to log this can someone let me know, I’ll be happy to do it. Thanks, *Guy Sherman* web: http://www.guysherman.com -- This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you. ___ 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] Unknown build error on Fedora x86_64
Hi, First, I'm getting further with the build for Mono on Fedora! However, I've hit this which I've never seen before. It seems to hit Fedora 14 as well as rawhide. Any ideas? *** ERROR: No build ID note found in /home/paul/rpmbuild/BUILDROOT/mono-2.10.1-1.fc16.x86_64/usr/lib64/mono/2.0/ mcs.exe.so error: Bad exit status from /var/tmp/rpm-tmp.1YSSNm (%install) TTFN Paul ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unknown build error on Fedora x86_64
Hi, Those files are created by our AOT compiler either directly using an ELF writer, or by using as+ld. I assume rpm wants the Build ID added by gcc to files it creates. You can try removing the mscorlib.dll.so/mcs.exe.so files after the build, those should not be part of the rpm package anyway. On Mon, Mar 7, 2011 at 7:14 PM, Paul Johnson p...@all-the-johnsons.co.ukwrote: Hi, First, I'm getting further with the build for Mono on Fedora! However, I've hit this which I've never seen before. It seems to hit Fedora 14 as well as rawhide. Any ideas? *** ERROR: No build ID note found in /home/paul/rpmbuild/BUILDROOT/mono-2.10.1-1.fc16.x86_64/usr/lib64/mono/2.0/ mcs.exe.so error: Bad exit status from /var/tmp/rpm-tmp.1YSSNm (%install) TTFN Paul ___ 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] [PATCH] Replace ENABLE_COREE with a runtime switch.
This patch mostly reverts 666d37829304e85f72969c44e92bc11ca167a272,
which put Mono's mixed-mode support in #ifdef ENABLE_COREE, disabling
it by default on Windows.
It was disabled because it broke the verifier, and it still does.
Since most of the new behavior is dependent on whether coree has been
hooked, or whether a particular image has been loaded using the OS
loader, skipping the hook step effectively disables coree at runtime.
So this patch moves that step out of mono_init_internal and into
mono_main, where it is dependent on a runtime switch.
Even if this didn't break the verifier, I think it's an intrusive,
hacky change to how Mono loads things that almost no one needs, and so
having it default off makes sense. Also, (my real motive) it's a step
towards my goal of getting Wine's builtin mscoree.dll to use Mono's
mixed-mode support without indirectly causing itself to be hooked.
From 1a6218abd8a3bec45d09cb2ff3b1404eb0ffa8f2 Mon Sep 17 00:00:00 2001
From: Vincent Povirk vinc...@codeweavers.com
Date: Mon, 7 Mar 2011 13:41:46 -0600
Subject: [PATCH] Replace ENABLE_COREE with a runtime switch.
---
mono/metadata/assembly.c |2 +-
mono/metadata/coree.c|7 ---
mono/metadata/domain.c |5 +
mono/metadata/image.c| 26 +-
mono/mini/driver.c | 17 +++--
5 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/mono/metadata/assembly.c b/mono/metadata/assembly.c
index cc9e980..621e450 100644
--- a/mono/metadata/assembly.c
+++ b/mono/metadata/assembly.c
@@ -1634,7 +1634,7 @@ mono_assembly_load_from_full (MonoImage *image, const
char*fname,
loaded_assemblies = g_list_prepend (loaded_assemblies, ass);
mono_assemblies_unlock ();
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
mono_image_fixup_vtable (image);
#endif
diff --git a/mono/metadata/coree.c b/mono/metadata/coree.c
index c31dfaf..9e48a3f 100644
--- a/mono/metadata/coree.c
+++ b/mono/metadata/coree.c
@@ -33,14 +33,10 @@
#include environment.h
#include coree.h
-#ifdef ENABLE_COREE
-
HMODULE coree_module_handle = NULL;
static gboolean init_from_coree = FALSE;
-#endif
-
gchar*
mono_get_module_file_name (HMODULE module_handle)
{
@@ -73,7 +69,6 @@ mono_get_module_file_name (HMODULE module_handle)
return file_name_utf8;
}
-#ifdef ENABLE_COREE
/* Entry point called by LdrLoadDll of ntdll.dll after _CorValidateImage. */
BOOL STDMETHODCALLTYPE _CorDllMain(HINSTANCE hInst, DWORD dwReason, LPVOID
lpReserved)
{
@@ -928,6 +923,4 @@ mono_fixup_exe_image (MonoImage* image)
MonoFixupExe ((HMODULE) image-raw_data);
}
-#endif /* ENABLE_COREE */
-
#endif /* HOST_WIN32 */
diff --git a/mono/metadata/domain.c b/mono/metadata/domain.c
index 8e001df..cbeef36 100644
--- a/mono/metadata/domain.c
+++ b/mono/metadata/domain.c
@@ -1271,9 +1271,6 @@ mono_init_internal (const char *filename, const char
*exe_filename, const char *
#ifdef HOST_WIN32
/* Avoid system error message boxes. */
SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX);
-#ifdef ENABLE_COREE
- mono_load_coree (exe_filename);
-#endif
#endif
mono_perfcounters_init ();
@@ -1312,7 +1309,7 @@ mono_init_internal (const char *filename, const char
*exe_filename, const char *
* exe_image, and close it during shutdown.
*/
get_runtimes_from_exe (exe_filename, exe_image, runtimes);
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (!exe_image) {
exe_image = mono_assembly_open_from_bundle
(exe_filename, NULL, FALSE);
if (!exe_image)
diff --git a/mono/metadata/image.c b/mono/metadata/image.c
index 5d098a0..ef904da 100644
--- a/mono/metadata/image.c
+++ b/mono/metadata/image.c
@@ -121,7 +121,7 @@ mono_cli_rva_image_map (MonoImage *image, guint32 addr)
for (i = 0; i top; i++){
if ((addr = tables-st_virtual_address)
(addr tables-st_virtual_address +
tables-st_raw_data_size)){
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
return addr;
#endif
@@ -158,7 +158,7 @@ mono_image_rva_map (MonoImage *image, guint32 addr)
if (!mono_image_ensure_section_idx (image, i))
return NULL;
}
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
return image-raw_data + addr;
#endif
@@ -239,7 +239,7 @@ mono_image_ensure_section_idx (MonoImage *image, int
section)
if (sect-st_raw_data_ptr + sect-st_raw_data_size
image-raw_data_len)
return FALSE;
-#ifdef ENABLE_COREE
+#ifdef HOST_WIN32
if (image-is_module_handle)
iinfo-cli_sections [section] = image-raw_data +
Re: [Mono-dev] PDB native support in C from C# open source project
On Mon, Mar 7, 2011 at 9:41 AM, David Marsh dmars...@hotmail.com wrote: Ref :- http://www.mono-project.com/StudentProjects#Native_support_for_PDB I'd be interested in contributing in this area, is it still an open item ? I believe so, yes. It would be particularly interesting to add full support for the local mappings that pdb has for nested scopes and iterator scopes, and propagate that information into the soft debugger, since Mono's mdb format doesn't currently support those. That would help to fix a few problems we have right now in the debugger - inspecting captured variables in anonymous delegates and iterators, and inspecting multiple variables with the same name in sub-scopes of a single method. We could then either propagate those features back into the mdb format, or switch to pdb entirely. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
