Hello,
This is sort of a correct list (mono-list may be better unless mono
development is involved).
I have no idea on from which this list addition occurs. This might not
happen in the latest git head or daily builds (but I doubt that). If you
can provide the runnable example code, I can
On Thu, Aug 12, 2010 at 2:06 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
I have no idea on from which this list addition occurs. This might not
happen in the latest git head or daily builds (but I doubt that). If you can
provide the runnable example code, I can test it on the
Hello,
For random results, it is rather likely that 2.6 HttpTransport listener
confuses between the contract service endpoint and WSDL/debug endpoint
(i.e. WSDL endpoint could try to process the contract messages, or the
contract endpoint may try to process WSDL requests). Explicitly
Does mono embedding work with valgrind? when I valgrind the embedded exe, it
reports massive errors.
Like this?
==8787== 2,032 bytes in 1 blocks are definitely lost in loss record 2,718 of
3,073
==8787==at 0x4A05140: calloc (vg_replace_malloc.c:418)
==8787==by 0x3CBBC33B81: g_malloc0
On 12.08.2010 14:44, xen wrote:
Does mono embedding work with valgrind? when I valgrind the embedded exe, it
reports massive errors.
It does, but you need mono's valgrind suppression file:
http://github.com/mono/mono/blob/master/data/mono.supp
Robert
You may generate the ILASM sources and assemble with debugging enabled.
Fun,
Rafael Monoman Teixeira
---
To be creative means to be in love with life. You can be creative
only if you love life enough that you want to enhance its beauty, you
want to bring a
thank for the supp file, but after I ran with it I am still getting errors...
Is my embedding code correct?
==14108== 1 errors in context 3 of 2325:
==14108== Use of uninitialised value of size 8
==14108==at 0x548D764: GC_find_header (headers.c:41)
==14108==by 0x5489F84:
I compiled a C so lib on Linux to do ioctl calls and tried to use it
with DllImport but when I pass structures by ref or StringBuilder for
returning char* buffers to my library everything is behaving strange.
The StringBuilders returned do not contain anything or I have to create
a new
Ok fair enough, I'll implement your suggestions.
You know, it's not that I don't like to document stuff (I'm almost done
porting [1] to [2] so we can replace it in [3] ;) )
Regards,
Andrés
[1] http://www.mono-project.com/Compiling_Mono_From_SVN
[2]
On 12.08.2010 16:49, Omar Siam wrote:
What am I missing? How do I compile so libs to be mono friendly?
Your post is missing a sample :) Post the p/invoke and structure
defs of both sides (managed and unmanaged).
Robert
___
Mono-devel-list mailing
On Thu, 2010-08-12 at 16:49 +0200, Omar Siam wrote:
I compiled a C so lib on Linux to do ioctl calls and tried to use it
with DllImport but when I pass structures by ref or StringBuilder for
returning char* buffers to my library everything is behaving strange.
Hello,
I'm almost done
porting [1] to [2] so we can replace it in [3] ;) )
This is music to my ears!
[1] http://www.mono-project.com/Compiling_Mono_From_SVN
[2] http://www.mono-project.com/Compiling_Mono_From_Git
[3] http://www.mono-project.com/Compiling
Hello. I have an existing Visual Studio solution (VS 2010) file that I am
porting to Mono. The whole solution does not have to build in Mono and I don't
want to maintain two different build files. I have two platform configurations
in the solution. The Win32 platform will build everything
I am currently porting an application to Mono that requires Active Directory
integration, but can't seem to get the same code base to run under .NET 3.5
and Mono. I am using Mono 2.6.4, but I've also tried a build of 2.6.7. For
example, if I want to fetch the defaultNamingContext, I can do it in
14 matches
Mail list logo
