[Mono-dev] threadpool win32 breakage, getting worse
Gonzalo, Can you please fix Windows threadpool issue first before it becomes worse than the previous state that we could only revert it to 32b3b31? Now we cannot even revert it to that revision: threadpool.c:2025: error: too few arguments to function `mono_thread_create_internal' threadpool.c:2027: error: too few arguments to function `mono_thread_create_internal' threadpool.c: In function `ves_icall_System_Threading_ThreadPool_SetMaxThreads': threadpool.c:2048: warning: passing arg 1 of `InterlockedExchange' from incompatible pointer type threadpool.c:2049: warning: passing arg 1 of `InterlockedExchange' from incompatible pointer type make[3]: *** [libmonoruntime_la-threadpool.lo] Error 1 make[3]: Leaving directory `/home/atsushi/svn/mono/mono/metadata' Now WCF is not hackable state again. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi, I got the thing to work... but I' am not very thrilled with the resolution... It seems like it'll work only if I use the same string for both MonoDomain creation thru mono_jit_init and also for loading assembly thru mono_domain_assembly_open.. In essense I am having to pass the assembly file path string even for the Domain, I used to think that it just requires a string name for the domain. But with this issue gone.. when I continued my work I hit upon another issue: My managed app uses the Mono.Unix.UnixDirectoryInfo class and at the instantiation of this class I get an exception that says : Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall --- System.DllNotFoundException: MonoPosixHelper at (wrapper managed-to-native) Mono.Unix.Native.Syscall:_L_ctermid () at Mono.Unix.Native.Syscall..cctor () [0x0] in :0 --- End of inner exception stack trace --- at Mono.Unix.UnixFileSystemInfo.GetFileStatus (System.String path, Mono.Unix.Native.Stat stat) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo.Refresh (Boolean force) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo..ctor (System.String path) [0x0] in :0 at Mono.Unix.UnixDirectoryInfo..ctor (System.String path) [0x0] in :0 at SimpleScanner.Program.Main (System.String[] args) [0x0] in :0 I am trying this on Mac OSX and I dont get this problem if I run my exe directly from Terminal using: Mono . So how is the environment different in case of Mono Embedding for this to happen. Any help is highly appreciated... Thanks in advance. -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3356206.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
Re: [Mono-dev] Embedding Mono
If you saw the example code I sent I was passing the full path to the EXE to both mono_jit_init and mono_domain_assembly_open. The purpose of embedding is to embed the Mono runtime into your app so that it runs without installing Mono. This error indicates the embedded runtime could not find the MonoPosixHelper dll or dylib. When running mono from the terminal you have the fully installed mono runtime so everything resolved. In my code before calling mono_jit_init I do this: NSString *mPath = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@Contents/Libraries/lib]; mono_assembly_setrootdir([mPath UTF8String]); Then I have the folder structure: MyApp.app/Contents/Libraries/lib/mono/2.0/mscorlib.dll MyApp.app/Contents/Libraries/*.dll MyApp.app/Contents/Libraries/libmono-2.0.1.dylib MyApp.app/Contents/Libraries/MyApp.exe I have all DLLs my app depends on. For example, System.Configuration.dll, System.dll, System.Core.dll, Mono.Posix.dll, etc. As well as my DLLs. Your app may also depend on: /Library/Frameworks/Mono.framework/Versions/2.8.2/lib/libMonoPosixHelper.dylib So you have to include that file in the Libraries folder as well as link against it so that it loads at runtime. You can also manually call dlopen passing the correct path to libMonoPosixHelper.dylib. Correct being relative or full, though I recommend full. I do not know how you are compiling your OSX app but otool and install_name_tool were very useful in my understanding of the embedding process. There are also older threads on the mono mailing lists that have more details. You can do a google search to find them mono embed osx duane. http://go-mono.com/forums/#nabble-td1548393 http://web.archiveorange.com/archive/v/IMVlhkecSBeuoQZ4wDcv Hope that helps you move along. Duane On Tue, Mar 15, 2011 at 6:45 AM, vinay_rk vinay.kash...@ironmountain.comwrote: Hi, I got the thing to work... but I' am not very thrilled with the resolution... It seems like it'll work only if I use the same string for both MonoDomain creation thru mono_jit_init and also for loading assembly thru mono_domain_assembly_open.. In essense I am having to pass the assembly file path string even for the Domain, I used to think that it just requires a string name for the domain. But with this issue gone.. when I continued my work I hit upon another issue: My managed app uses the Mono.Unix.UnixDirectoryInfo class and at the instantiation of this class I get an exception that says : Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall --- System.DllNotFoundException: MonoPosixHelper at (wrapper managed-to-native) Mono.Unix.Native.Syscall:_L_ctermid () at Mono.Unix.Native.Syscall..cctor () [0x0] in :0 --- End of inner exception stack trace --- at Mono.Unix.UnixFileSystemInfo.GetFileStatus (System.String path, Mono.Unix.Native.Stat stat) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo.Refresh (Boolean force) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo..ctor (System.String path) [0x0] in :0 at Mono.Unix.UnixDirectoryInfo..ctor (System.String path) [0x0] in :0 at SimpleScanner.Program.Main (System.String[] args) [0x0] in :0 I am trying this on Mac OSX and I dont get this problem if I run my exe directly from Terminal using: Mono . So how is the environment different in case of Mono Embedding for this to happen. Any help is highly appreciated... Thanks in advance. -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3356206.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
[Mono-dev] Mono-2.10.1 Cross compile on Arm: Build problems
Hi
I'm using an i686 machine to cross compile for an arm embedded target, using
arm-iwmmxt-linux-gnueabi toolchain.
I am using the configuration settings below:
CC=/home/ndick/Cross_Library/crosstool/bin/arm-iwmmxt-linux-gnueabi-gcc
./configure --host=arm-iwmmxt-linux-gnueabi
--prefix=/usr/local/arm-iwmmxt-linux-gnueabi --enable-nls=no --with-tls=pthread
--with-sigaltstack=no --with-expat=builtin --with-static_mono=yes
mono_cv_uscore=${mono_cv_uscore=no}
The build fails during the make stage when it fails to find the library -
libmono-2.0.so.1.0.0 (linked to by mono/mini/.libs/libmono-2.0.so). (See log
below)
My question is how can I get an arm version of this library to be built?
I checked the configure --help and couldnt see an obvious switch to set or
maybe its my configuration settings are wrong somewhere??
Any help would be appreciated!!
Thanks
Nige
:-)
CC libmonosgen_static_la-exceptions-arm.lo
CC libmonosgen_static_la-tramp-arm.lo
CC libmonosgen_static_la-mini-posix.lo
mini-posix.c: In function 'sigusr1_signal_handler':
mini-posix.c:202: warning: unused variable 'mctx'
LD libmonosgen-static.la
CC mono-main.o
LD mono
CC mono_sgen-main.o
LD mono-sgen
make[4]: Leaving directory `/home/ndick/Downloads/mono-2.10.1_arm/mono/mini'
make[3]: Leaving directory `/home/ndick/Downloads/mono-2.10.1_arm/mono/mini'
Making all in dis
make[3]: Entering directory `/home/ndick/Downloads/mono-2.10.1_arm/mono/dis'
CC get.o
CC dis-cil.o
CC util.o
rm -f libmonodis.a
arm-iwmmxt-linux-gnueabi-ar cru libmonodis.a get.o dis-cil.o util.o
arm-iwmmxt-linux-gnueabi-ranlib libmonodis.a
CC dump.o
CC main.o
CC declsec.o
LD monodis
arm-iwmmxt-linux-gnueabi-gcc: ../mini/.libs/libmono-2.0.so: No such file or
directory
make[3]: *** [monodis] Error 1
make[3]: Leaving directory `/home/ndick/Downloads/mono-2.10.1_arm/mono/dis'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ndick/Downloads/mono-2.10.1_arm/mono'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ndick/Downloads/mono-2.10.1_arm'
make: *** [all] Error 2
ndick@LinuxBox:~/Downloads/mono-2.10.1_arm$ ls -oal
mono/mini/.libs/libmono-2.0.so
lrwxrwxrwx 1 ndick 20 Mar 15 13:53 mono/mini/.libs/libmono-2.0.so -
libmono-2.0.so.1.0.0
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoImage vs MonoAssembly ?
Hi all, I'm new to .NET and Mono, so some of the terminology in the embedding API isn't quite clear to me. What's the difference between a MonoAssembly and a MonoImage? thanks, vic ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoImage vs MonoAssembly ?
Hello Victor, I'm new to .NET and Mono, so some of the terminology in the embedding API isn't quite clear to me. What's the difference between a MonoAssembly and a MonoImage? Assemblies are the unit of deployment in .NET and the container for the MonoImage, you will typically see those as either .dll or .exe files. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Setup script for installing Mono?
Has anyone written anything like a setup script with something like: ./parallel-mono-install.sh v2.10.1 --path=/opt/mono and if so, would they be willing to share? I'm finding it obnoxious to set up unstable Mono versions on new Ubuntu boxes. http://sadtrombone.com ~ jf -- John Feminella Principal Consultant, BitsBuilder LI: http://www.linkedin.com/in/johnxf SO: http://stackoverflow.com/users/75170/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Process.Start and WaitForExit on MacOS X
Regarding this post on Mono-OSX http://go-mono.com/forums/#nabble-td3251954 and
some of my own issues with Process.Start() on MacOS X.
I've discovered that Process.Start(ProcessStartInfo info) leaves child
processes hanging around until the parent process dies, unless you call
WaitForExit() on the child process.
An alternative is to do something like this: (see above forum link for the rest
of the code that this applies to).
using (var ioreg = Process.Start(ioregInfo)) {
ioreg.EnableRaisingEvents = true;
EventHandler handler;
handler = (s,e) = { ioreg.Exited -= handler; ioreg.WaitForExit(); };
ioreg.Exited += handler;
// Do something with the process
}
If you don't call WaitForExit() in some way on the process, the child processes
hang around until the parent process dies and you end up with fork() returning
–1 with an EAGAIN error code because you'll have exceeded the maximum number of
processes allowed per uid.
Is this a bug or by design?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
I do not know how you are compiling your OSX app but otool and install_name_tool were very useful in my understanding of the embedding process. If you linking against shared libraries and using install_name_tool, you'll also want to provide the linker flag -headerpad_max_install_names. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.Start and WaitForExit on MacOS X
On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote: I've discovered that Process.Start(ProcessStartInfo info) leaves child processes hanging around until the parent process dies, unless you call WaitForExit() on the child process. ... Is this a bug or by design? The problem is the Process.ExitCode property. There's no way to retrieve this value except through the waitpid(2) (and related) system calls, so the process can't be fully disposed just in case the ExitCode property will be accessed. That said, once the instance has been disposed, it shouldn't be necessary to keep anything open, and the child handles should be closed. Given that you _are_ using a `using` block, and thus disposing of the instance, it seems that this is likely a bug and that Process.Dispose() isn't fully closing all resources as it should. (For that matter, the Process finalizer should also be disposing of unmanaged resources, and it looks like that isn't the case either). Could you please file a bug? Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.Start and WaitForExit on MacOS X
Submitted bug with a reproducible test case: https://bugzilla.novell.com/show_bug.cgi?id=679936 On 3/15/11 12:26 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote: I've discovered that Process.Start(ProcessStartInfo info) leaves child processes hanging around until the parent process dies, unless you call WaitForExit() on the child process. ... Is this a bug or by design? The problem is the Process.ExitCode property. There's no way to retrieve this value except through the waitpid(2) (and related) system calls, so the process can't be fully disposed just in case the ExitCode property will be accessed. That said, once the instance has been disposed, it shouldn't be necessary to keep anything open, and the child handles should be closed. Given that you _are_ using a `using` block, and thus disposing of the instance, it seems that this is likely a bug and that Process.Dispose() isn't fully closing all resources as it should. (For that matter, the Process finalizer should also be disposing of unmanaged resources, and it looks like that isn't the case either). Could you please file a bug? Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.Start and WaitForExit on MacOS X
Apparently, the bug I filed was marked as a duplicate of this WONTFIX bug: https://bugzilla.novell.com/show_bug.cgi?id=668867 According to the resolution of that bug, I just need to enable shared handles. Unless I'm doing something wrong, enabling shared handles should be as simple as MONO_ENABLE_SHM=1 mono ProcessTest.exe, right? That doesn't seem to fix the issue. We're finding that running CruiseControl.Net under Mono creates zombies because the processes aren't waited for, and this happened even in 2.6, where IIRC, shared handles were enabled by default. Thanks, Tom On 3/15/11 2:15 PM, Tom Philpot tom.phil...@logos.com wrote: Submitted bug with a reproducible test case: https://bugzilla.novell.com/show_bug.cgi?id=679936 On 3/15/11 12:26 PM, Jonathan Pryor jonpr...@vt.edu wrote: On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote: I've discovered that Process.Start(ProcessStartInfo info) leaves child processes hanging around until the parent process dies, unless you call WaitForExit() on the child process. ... Is this a bug or by design? The problem is the Process.ExitCode property. There's no way to retrieve this value except through the waitpid(2) (and related) system calls, so the process can't be fully disposed just in case the ExitCode property will be accessed. That said, once the instance has been disposed, it shouldn't be necessary to keep anything open, and the child handles should be closed. Given that you _are_ using a `using` block, and thus disposing of the instance, it seems that this is likely a bug and that Process.Dispose() isn't fully closing all resources as it should. (For that matter, the Process finalizer should also be disposing of unmanaged resources, and it looks like that isn't the case either). Could you please file a bug? Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
