RE: [Mono-dev] Compilling Mono 1.1.10 on Sun Solaris 9
I believe that that library is in /usr/ucblib and is there by default (I don't know that for sure, since we have Workshop installed). That issue is just a path issue and there will likely be others (I haven't tried building Solaris Mono for a while so I don't know what sort of shape it is in). Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vorobiev Maksim Sent: Monday, December 19, 2005 11:49 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Compilling Mono 1.1.10 on Sun Solaris 9 Good day. I try to compile Mono 1.1.10 on Sun Solaris 9 (SPARC), but it throws error at /mono/dis/get.c: undefined reference to `isnormal'. I've found submitted bug about the same problem, but for Solaris 8. Bug № 77034. The problem is that the function isnormal not implemented in standart Sun's libm, but only in additional libsunmath, that ships with Sun Workshop. Is it possible to break this dependance? As I can see, this call branches some sort of print output (debug propose?). Is it OK to comment out call to isnormal, or it breaks something internal? May be it's good to make conditional compilation branch for Sun platform? 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
RE: [Mono-dev] default_opt and aot
When running exception.exe after the test_0_ulong_cast (both tests did fail with 1 and 4 as the values instead of 0). Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Zoltan Varga [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 8:54 AM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] default_opt and aot Hi, default_opt is initialized in mini_init () before aot_init is called, so this should not happen. Which test is core dumping for you ? Zoltan On 8/31/05, Gary Smithrud [EMAIL PROTECTED] wrote: I'm trying to get the 8/29 source tarball built on Solaris and it is core dumping when performing make check. The issue is that mono_aot_get_method is being called and aot_mutex is 0 (the coredump is occurring in LeaveCriticalSection.) It looks like that the default_opt of 0 is causing the aot_init to not be called and thus the aot_mutex is not initialized. Is there a way to set the default_opt from outside (I don't have time to track down how to do this)? ___ 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] GC_thread_register_foriegn and Solaris 8
Thanks!! Very much appreciated! Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Zoltan Varga [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 2:15 PM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] GC_thread_register_foriegn and Solaris 8 Hi, This is now fixed in SVN. Zoltan On 8/24/05, Gary M. Smithrud [EMAIL PROTECTED] wrote: I'm attempting to get the 8/23 tarball to compile under Solaris 8 and the function GC_thread_register_foriegn is undefined. I've checked for incorrectly defined #if around this function, but everything looks like it is defined appropriate. I've also attempted to mark this function as a GC_API to export it to the library. I am using gcc to compile. Should this function be used on Solaris and if so does someone know how to make it available (I did check the libmonogc.a for the symbol, but no luck there either). Thanks. Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JD Conley Sent: Wednesday, August 24, 2005 1:50 PM To: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Subject: RE: [Mono-dev] Novell.Directory.Ldap in the Mono tree I was wondering if there was any synchronization between Novell.Directory.Ldap on Novell forge and Mono. I have noticed that the trees are currently fairly different. I'm trying to make a decision on which to patch, but I don't really know. I am leaning toward patching the one on Novell forge since that seems to be the root, but then when, if ever, would my fixes show up in the Mono tree? Would I be stuck building my own version of Novell.Directory.Ldap for distribution? Is there any particular reason why I should modify the one in the Mono tree vs. the one in Novell Forge? Would you be interested in merging the changes from the official Novell build into our tree? That's certainly a possibility, but I wouldn't want to do it if it was something that was going to have to be maintained in separate branches going into the future. There really should be only one branch, maybe with separate build scripts and some defines for Mono's TARGET_JVM and anything else that's needed. -JD ___ 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
RE: [Mono-devel-list] Issue with mono_debugger_add_type on Solaris SPARC.
Thanks! Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Zoltan Varga [mailto:[EMAIL PROTECTED] Sent: Sunday, August 07, 2005 11:15 AM To: Gary M. Smithrud Cc: mono-devel Subject: Re: [Mono-devel-list] Issue with mono_debugger_add_type on Solaris SPARC. Hi, This particular issue is already fixed in SVN, however some other alignment issues remain, so --debug is currently unusable on SPARC. Zoltan On 8/5/05, Gary M. Smithrud [EMAIL PROTECTED] wrote: Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change The issue with mono_debugger_add_type is with the following lines (from memory, since I am on a different machine): write_leb(...); write_leb(...); write_leb(...); * ((gpointer*) ptr) = klass; Write_leb can move the pointer to an offset that is not on a pointer boundary and the SPARC architecture does not allow a pointer to be written on an odd boundary (or word boundaries that are not also long boundaries, ie pointer % 4 != 0...actually, it probably even pointer % 8 != 0 for 64-bit). I've change the code to behave as though they were two guint8* (which is convenient, since one is defined that way) and loop through the data. I do not know what the data is used for, I am unsure that that is appropriate. ___ 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] Issue with mono_debugger_add_type on Solaris SPARC.
Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change The issue with mono_debugger_add_type is with the following lines (from memory, since I am on a different machine): write_leb(...); write_leb(...); write_leb(...); * ((gpointer*) ptr) = klass; Write_leb can move the pointer to an offset that is not on a pointer boundary and the SPARC architecture does not allow a pointer to be written on an odd boundary (or word boundaries that are not also long boundaries, ie pointer % 4 != 0...actually, it probably even pointer % 8 != 0 for 64-bit). I've change the code to behave as though they were two guint8* (which is convenient, since one is defined that way) and loop through the data. I do not know what the data is used for, I am unsure that that is appropriate. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Thread SpinWait not supported? Interrupt ?
I think that this answers it: Search of archives shows 2002/2003 mail-list items saying its a TODO, and not high priority And it's probably still not a high priority. SpinWait is a more efficient wait then the standard blocking mechanism (in most cases), but since it is only a more efficient version of Wait it is not implemented yet. SpinWait goes into a loop to grab the lock before giving up and entering the wait state...and no, it is actually more efficient because if you can grab the lock before entering the wait state, the better the performance. Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ted leslie Sent: Sunday, July 31, 2005 2:37 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-devel-list] Thread SpinWait not supported? Interrupt ? Unhandled Exception: System.NotImplementedException: The requested feature is not implemented. in 0x0001d System.Threading.Thread:SpinWait (Int32 iterations) in 0x00072 ServerClass:StaticMethod () in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () I tried a Thread.SpinWait / Interrupt demo program ... and mono doesn't support SpinWait ? Its an inefficent function, but if someone were to use it in MS .Net and expect there code to work on Mono? Then having said that, SpinWait and Interrupt seem to be a matching pair, so without SpinWait, what is Interrupt going to be used for? It doesn't seem to Interrupt Sleep(). Search of archives shows 2002/2003 mail-list items saying its a TODO, and not high priority I have read some workarounds, but I can't help but think if Interrupt is supposed to also interrupt a Sleep, this would be handy. Is there a big implementation delima? Or is it not considered a high priority? On to the suggested work around ... On Fri, 2003-02-28 at 11:53, Yury Serdyuk wrote: Hi ! We see in the List of not-implemented classes that the Interrupt - method didn't realized yet. In particular, the following program doesn't work properly : But this function is very important for multithreading applications. So, tell us about the current status of this problem, Thread.Interrupt() has not been implemented, and it is way down on my todo list. or is there a walk-around of it ? Use events to signal state changes between threads? - Dick -tl ___ 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-devel-list] PEAPI and 1.1.8.3 build
That's it! Thanks! Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: Atsushi Eno [mailto:[EMAIL PROTECTED] Sent: Thursday, July 28, 2005 10:38 AM To: Gary M. Smithrud Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-devel-list] PEAPI and 1.1.8.3 build Hi, Gary M. Smithrud wrote: I'm attempting to build 1.1.8.3 on Solaris (if anyone has any experience doing this and has suggestions, let me know) and it fails because it is attempting to build PEAPI, which is not part of the tarball. Is this needed? I'm not sure whether I should comment it out of the makefile or attempt to get it from one of the branches (main?). Thanks! PEAPI is part of the tarball. Check if your tar command works fine. (i.e. try GNU tar instead of the pre-installed one.) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Re: development of monodevelop: why? :P
I am guessing here, but it could be difficult to get a debugger that is not Java related into that environment. I've seen other plug-ins for doing other languages, but I have not seen one where you got a debugger as well. Instead you just get syntax highlighting, etc. Besides, Eclipse is not THAT great of an environment. Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KCorax Sent: Wednesday, July 13, 2005 12:48 PM To: Robert Jordan Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-devel-list] Re: development of monodevelop: why? :P Considering that the mono-develop list is a spinoff to this one, this is not off-topic. It is essentially an existance related inquiry to a mother list. As for posting to them, I didnt really get an answer as to why there is a need to fork sharp-develop, I do not see why there would be an answer regarding eclipse. O/H Robert Jordan έγραψε: Dominik, I didnt post here because I couldnt find a plugin (I admit I didnt try ;)) I posted here because I wondered (and still do) why there is monodevelop. Is there a ...technical reason... is it just for fun.. or just because you dont like eclsipse.or I DONT KNOW :) You're totally off-topic with this subject on this list. Here is the MonoDevelop list: http://lists.ximian.com/mailman/listinfo/monodevelop-list Don't forget to put your fireproof pants on before posting. 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Default:ChangeType, MonoType, dynamically loaded assemblies and MonoCMethod:Invoke on constructors
I'm back in town and have had a chance to look into this issue and it
looks like the problem is not related to the assemblies and loading them
(which is good news). Is there information about how complete the
SortedList class is? I notice a comment in the documentation of 1.1.7
that implied that it was not fully implemented, but that was about it.
I am using 1.1.8.1. I would really love to get my hands on MonoDevelop
for this version (I've tried to build it but no luck). Thanks for the
information.
Gary M. Smithrud
Haley Systems, Inc.
Phone: 724-934-7853
[EMAIL PROTECTED]
www.haley.com
Moving at the Speed of Change
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gary M.
Smithrud
Sent: Thursday, June 16, 2005 7:55 PM
To: mono-devel-list
Subject: [Mono-devel-list] Default:ChangeType, MonoType,dynamically
loaded assemblies and MonoCMethod:Invoke on constructors
I have the following two assemblies that are being loaded dynamically
from within an application. In the constructor for a class in the first
assembly, it has a parameter that is an instance of a class in the
second assembly. When attempting to call the constructor for the first
class (using reflection), I get the exception System.ArgumentException:
parameters (by the way, this exception could really provide more
information or the outer one should so that way it is a little easier to
track the problem down).
Looking at the trace, it looks like the compile MonoType is different
than the MonoType for the same class when loading the assembly
dynamically (determined this by the tracing/debugging output). The
application does not have access to the assemblies when it is built, nor
does it know the order in which they are loaded. The first assembly
does reference the second one when it is built, of course. In the
trace, the object that is passed in the array has the correct type, but
the type's are different when they are compared in Default:ChangeType (I
do not know what type Mono believes it is, because I have not been able
to get Mono-Develop to build. I am not sure that I can get that
information from gdb either.)
The question is, Has this been tested and the problem is in my code or
does Mono have an issue with this? Unfortunately, I am leaving town
tomorrow and do not have time right now to provide an example. Below is
code that sort of shows the issue:
using B;
namespace A {
public abstract class ClassA {
ClassC _foo; // In B.
double _value;
int number;
public ClassA(ClassC foo, double value, int number) {
_foo = _foo;
_value = value;
_number = number;
}
}
public ClassB : ClassA {
public ClassB(ClassC foo, double value, int number) :
base(foo,value,number) {
// do whatever
}
}
}
namespace B {
public ClassC {
}
}
The exception occurs when you pass an instance of B.ClassC to the
constructor of ClassB.
Thanks for any information (again, I will be out of town until Tuesday,
if you have any questions),
Gary.
___
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] Default:ChangeType, MonoType, dynamically loaded assemblies and MonoCMethod:Invoke on constructors
I have the following two assemblies that are being loaded dynamically
from within an application. In the constructor for a class in the first
assembly, it has a parameter that is an instance of a class in the
second assembly. When attempting to call the constructor for the first
class (using reflection), I get the exception System.ArgumentException:
parameters (by the way, this exception could really provide more
information or the outer one should so that way it is a little easier to
track the problem down).
Looking at the trace, it looks like the compile MonoType is different
than the MonoType for the same class when loading the assembly
dynamically (determined this by the tracing/debugging output). The
application does not have access to the assemblies when it is built, nor
does it know the order in which they are loaded. The first assembly
does reference the second one when it is built, of course. In the
trace, the object that is passed in the array has the correct type, but
the type's are different when they are compared in Default:ChangeType (I
do not know what type Mono believes it is, because I have not been able
to get Mono-Develop to build. I am not sure that I can get that
information from gdb either.)
The question is, Has this been tested and the problem is in my code or
does Mono have an issue with this? Unfortunately, I am leaving town
tomorrow and do not have time right now to provide an example. Below is
code that sort of shows the issue:
using B;
namespace A {
public abstract class ClassA {
ClassC _foo; // In B.
double _value;
int number;
public ClassA(ClassC foo, double value, int number) {
_foo = _foo;
_value = value;
_number = number;
}
}
public ClassB : ClassA {
public ClassB(ClassC foo, double value, int number) :
base(foo,value,number) {
// do whatever
}
}
}
namespace B {
public ClassC {
}
}
The exception occurs when you pass an instance of B.ClassC to the
constructor of ClassB.
Thanks for any information (again, I will be out of town until Tuesday,
if you have any questions),
Gary.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Preview of release notes.
I was able to get to the link fine, so there is some other issue. On Tuesday 14 June 2005 10:30, RafaelMizrahi wrote: Miguel, The link is broken. rafi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel de Icaza Sent: Tuesday, June 14, 2005 5:25 PM To: [EMAIL PROTECTED] Subject: [Mono-devel-list] Preview of release notes. Here is a preview of the release notes, please send me updates before the release: http://www.go-mono.com/archive/1.1.8/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Need help with DllImport.
Thank you! That was indeed the issue (gcc being used on some of the libraries
that were using C++ code). The problem, of course, was that other
applications built with the libraries were appropriate linked, but the
libraries were not. Gotta love the fact that gcc can compile C++ code.
Gary.
On Friday 03 June 2005 18:22, Jonathan Pryor wrote:
On Fri, 2005-06-03 at 09:56 -0400, Gary M. Smithrud wrote:
The DLL containing the InitializeKnowledgeBase relies on other shared
libraries that are also part of the project and under Mono 1.1.4 I could
create a single library that reference the others and it would work then
(definitely not ideal).
Sounds like you're improperly linking your library. When you link your
library, you should link against all other dependent libraries:
$ gcc -shared -out libfoo.so foo.c -ldep1 -ldep2 -ldep3 # ...
A perfect prior example is creating a C++ shared library which uses
`std::cout` but using `gcc` instead of `g++` to link the .so. This
results in libstdc++.so *not* being loaded at runtime, resulting in
strange library loading errors like you're describing.
The perfect test for this is a small program which dlopen(3)'s your
library with RTLD_NOW. If it can be loaded, your library is fine,
otherwise you have a dependency problem. (dlerror(3) can be used to
obtain an error message after a failed attempt loading the library.)
For example:
/*
* dlopen test program for libraries
*
* Compile as: gcc -o dltest dltest.c -ldl
*/
#include stdio.h
#include dlfcn.h
int
main (int argc, char **argv)
{
int i;
for (i = 1; i argc; ++i) {
void *h;
h = dlopen (argv [i], RTLD_NOW);
if (h == NULL)
printf (error loading library `%s': %s,
argv [i], dlerror ());
if (h != NULL)
dlclose (h);
}
return 0;
}
The other thing to keep in mind is that mono translates SIGSEGV into a
System.NullReferenceException, so it's possible that you're getting a
null pointer in InitializeKnowledgeBase (perhaps bad structure
marshaling?), resulting in a SIGSEGV, and hence the
NullReferenceException.
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
