[Mono-dev] Error cross.compiling mono for MIPS
Hello List, I'm cross-compiling mono 3.12.0 for mips and found an error not present in mono 3.10.0: sgen-os-posix.c: In function 'suspend_thread': ../../mono/utils/mono-context.h:475:61: error: 'mips_sp' undeclared (first use in this function) #define MONO_CONTEXT_GET_SP(ctx) ((gpointer)((ctx)->sc_regs[mips_sp])) ^ sgen-os-posix.c:73:17: note: in expansion of macro 'MONO_CONTEXT_GET_SP' stack_start = MONO_CONTEXT_GET_SP (&ctx) - REDZONE_SIZE; ^ ../../mono/utils/mono-context.h:475:61: note: each undeclared identifier is reported only once for each function it appears in #define MONO_CONTEXT_GET_SP(ctx) ((gpointer)((ctx)->sc_regs[mips_sp])) ^ sgen-os-posix.c:73:17: note: in expansion of macro 'MONO_CONTEXT_GET_SP' stack_start = MONO_CONTEXT_GET_SP (&ctx) - REDZONE_SIZE; Can you help me understanding what's happening here? Thank you! -- Profile: http://it.linkedin.com/in/compagnucciangelo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas?
They could. The most obvious reason is that you need to figure out the makefile arcane magic, as I don't see any solution files which can be easily built with xbuild/Monodevelop. One thing is to bundle tools with Mono, the other one is to tightly integrate it so that apparently it can't be built with xbuild as standalone. On Fri, Jan 23, 2015 at 4:35 PM, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: Arthur Peka [mailto:artur.p...@gmail.com] > > > > stores). I want to improve usability, e.g. > > * Listing certificates from all the stores (except Untrusted) when > called with - > > -list -c without specifying the store. Now it fails when no store > specified. Can > > be useful to get all trusted certs. > > * When importing some well-known certificates (e.g. some Nuget-related), > > certificate is claimed to be invalid. Needs investigation. > > * Unit/integration tests > > * Colouring output for readability? > > * Other? > > Those sound like good improvements - but I don't see any reason they > shouldn't be part of mono. > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas?
> From: Arthur Peka [mailto:artur.p...@gmail.com] > > I don't see any solution files which can be easily > built with xbuild/Monodevelop. When you reply, please quote what you're responding to, and don't top post. Makes it hard to follow the conversation. (Etiquette.) You clearly have created solution & project files. I don't know how difficult it was, but maybe you missed this comment? http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] cert-sync
> From: Sebastien Pouliot [mailto:sebastien.poul...@gmail.com] > > No. WebClient, HttpWebRequest, the default HttpClient handler... all uses > SslStream which delegates the trust decision to the OS (on iOS, Android and > Mac). Wait - We've already established in this thread (see links below) that on Mac, SslStream.AuthenticateAsClient throws IOException if the Trust directories were empty or nonexistent, and SslStream.AuthenticateAsClient works fine if you've run mozroots, but on the same system with empty Trusts, WebClient.DownloadString works fine. This suggested that WebClient delegated trust to the OS, while SslStream used the .Net trust store. Are you saying that WebClient uses SslStream in some way different from using AuthenticateAsClient? I tested OSX SslStream.AuthenticateAsClient without mozroots. Failed. http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042668.html Alexander tested WebClient.DownloadString without mozroots. Succeeded. http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042672.html Alexander confirmed my results. http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042675.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas?
Hello, We have to revisit the build scripts that we started last year that are able to generate an entire solution/projects from the existing Makefiles. Miguel On Sat, Jan 24, 2015 at 9:10 AM, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: Arthur Peka [mailto:artur.p...@gmail.com] > > > > I don't see any solution files which can be easily > > built with xbuild/Monodevelop. > > When you reply, please quote what you're responding to, and don't top > post. Makes it hard to follow the conversation. (Etiquette.) > > You clearly have created solution & project files. I don't know how > difficult it was, but maybe you missed this comment? > http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas? (Mono-devel-list Digest, Vol 117, Issue 32)
>In the case of certmgr, was there any complexity in creating the solution in MD? If it's trivial, it might be reasonable for people to just >generate them when they need them. If it's non-trivial, it might not be unreasonable to include those in the mono sources. I beg to differ. There wasn't really any complexity there, but scaffolding takes time and energy. Proper solution file could at least be generated with make. Arthur. On Thu, Jan 22, 2015 at 2:25 PM, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > > boun...@lists.ximian.com] On Behalf Of Jo Shields > > > > it's > > easier to work with a standalone MD project than the whole Mono tree, > > when doing breakpointing & object inspection > > Something I've certainly done in the past to debug mono sources, was to > create a MD/XS solution in the mono source dir locally on my system, with a > really basic console application that referenced some mono classes, so I > could then debug my console app & step through mono source in the IDE. > After doing stuff, I chose to commit mono source changes and discard the > IDE scaffolding because it was trivial. > > In the case of certmgr, was there any complexity in creating the solution > in MD? If it's trivial, it might be reasonable for people to just generate > them when they need them. If it's non-trivial, it might not be > unreasonable to include those in the mono sources. > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas?
>We have to revisit the build scripts that we started last year that are able to generate an entire solution/projects from the existing Makefiles. Could you point where those are? Would be interesting to look through. >You clearly have created solution & project files. I don't know how difficult it was, but maybe you missed this comment? >http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html I missed it, as subject is different there, so it went to a separate thread. Arthur. On Sat, Jan 24, 2015 at 4:36 PM, Miguel de Icaza wrote: > Hello, > > We have to revisit the build scripts that we started last year that are > able to generate an entire solution/projects from the existing Makefiles. > > Miguel > > On Sat, Jan 24, 2015 at 9:10 AM, Edward Ned Harvey (mono) < > edward.harvey.m...@clevertrove.com> wrote: > >> > From: Arthur Peka [mailto:artur.p...@gmail.com] >> > >> > I don't see any solution files which can be easily >> > built with xbuild/Monodevelop. >> >> When you reply, please quote what you're responding to, and don't top >> post. Makes it hard to follow the conversation. (Etiquette.) >> >> You clearly have created solution & project files. I don't know how >> difficult it was, but maybe you missed this comment? >> http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html >> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fork of certmgr - any ideas? (Mono-devel-list Digest, Vol 117, Issue 32)
Yes, we have a partial project that does this. Not sure where we are at on it, but the last time I checked, it did most of the class libraries. On Sat, Jan 24, 2015 at 12:24 PM, Arthur Peka wrote: > >In the case of certmgr, was there any complexity in creating the solution > in MD? If it's trivial, it might be reasonable for people to just > >generate them when they need them. If it's non-trivial, it might not be > unreasonable to include those in the mono sources. > > I beg to differ. There wasn't really any complexity there, but scaffolding > takes time and energy. Proper solution file could at least be generated > with make. > > Arthur. > > On Thu, Jan 22, 2015 at 2:25 PM, Edward Ned Harvey (mono) < > edward.harvey.m...@clevertrove.com> wrote: > >> > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- >> > boun...@lists.ximian.com] On Behalf Of Jo Shields >> > >> > it's >> > easier to work with a standalone MD project than the whole Mono tree, >> > when doing breakpointing & object inspection >> >> Something I've certainly done in the past to debug mono sources, was to >> create a MD/XS solution in the mono source dir locally on my system, with a >> really basic console application that referenced some mono classes, so I >> could then debug my console app & step through mono source in the IDE. >> After doing stuff, I chose to commit mono source changes and discard the >> IDE scaffolding because it was trivial. >> >> In the case of certmgr, was there any complexity in creating the solution >> in MD? If it's trivial, it might be reasonable for people to just generate >> them when they need them. If it's non-trivial, it might not be >> unreasonable to include those in the mono sources. >> > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono_signature_get_desc segfaults
0 static char *
1 get_method_name(MonoProfiler *profiler, MonoMethod *method) {
2 MonoClass *klass = mono_method_get_class (method);
3 if(klass == NULL) return NULL;
4 char *signature = (char*) mono_signature_get_desc
(mono_method_signature (method), 0);
5 if(signature == NULL) return NULL;
6 const char *namespace = mono_class_get_namespace (klass);
7 const char *klassname = mono_class_get_name (klass);
8 const char *methodname = mono_method_get_class (method);
9 //g_free (signature);
10 char *name = g_strdup_printf ("%s.%s:%s (%s)",
11 mono_class_get_namespace (klass),
12 mono_class_get_name (klass),
13 mono_method_get_name (method),
14 signature);
15 return name;
16 }
I have been able to get it to happen rather reliably that I appear to
get back something that is a bad pointer from mono_signature_get_desc.
I am not seeing anything obviously wrong in how I am calling it but
will get a segv occasionally on the strdup_printf here. Not using the
signature makes issue go away but isnt much help:)
Am I missing something in how I should be calling get_desc? The
MonoMethod was handed to me by the runtime...
Cheers,
Greg
--
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Custom messaging provider doesn't seem to work
Mono.Messaging allows you to specify a custom messaging provider in the MONO_MESSAGING_PROVIDER appsetting. But it appears only to work with the RabbitMQ provider that’s packaged with Mono. Any value other than the pre-approved provider class name (or its alias) makes MessagingProviderLocator throw an exception in the static constructor. (1) Is this intentional or is it a bug/missing feature? Would a patch to allow any custom IMessagingProvider be welcomed? Thanks, Philip (1) https://github.com/mono/mono/blob/effa4c07ba850bedbe1ff54b2a5df281c058ebcb/mcs/class/Mono.Messaging/Mono.Messaging/MessagingProviderLocator.cs#L90 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
