[Mono-list] EntryPointNotFoundException: map_Mono_Posix_PollEvents

Ravindra Kumar rkumar@novell.com
Fri, 08 Oct 2004 09:04:15 -0600


Hi Shaun,
Sorry to disappoint you, it is not done yet. But,
we have plans to do it soon.

Regards,
- Ravi

>>> Shaun Jackman <sjackman@gmail.com> 10/08/04 8:27 PM >>>
Thanks Ravi! A make clean was in fact all it needed.

Does Managed.Windows.Forms have a ComboBox?

Cheers,
Shaun


On Thu, 07 Oct 2004 21:29:11 -0600, Ravindra Kumar <rkumar@novell.com>
wrote:
> Hi Shaun,
> 
> Ans [1]: It looks like you are using the old implementation. If you
use
> the
> new one, I think it will get solved.
> Ans [2]: You just need to do 'make clean' inside the new MWF
> directory.
> and then try 'make' and 'make install'.
> 
> -Ravi
> 
> >>> Shaun Jackman <sjackman@gmail.com> 10/08/04 2:19 AM >>>
> 
> 
> To be safe, I've removed all versions of Mono. I then installed mono
> 1.0.1 from Debian to bootstrap. I did make clean, cvs up,
autogen.sh,
> make bootstrap, make install. I then removed mono 1.0.1. Now, my
> application compiles fine, but it gives exceptions when I try to run
> it [1].
> While I was investigating, I tried to recompile
Managed.Windows.Forms.
> It fails because it cannot find AccessibleEvents.cs [2]. Do you have
> any pointers?
> 
> Thanks again,
> Shaun
> 
> [1]
> $ mono FocusRemote.exe
> Unhandled Exception: System.TypeInitializationException: An
exception
> was thrown by the type initializer for System.Windows.Forms.Control
> ---> System.TypeInitializationException: An exception was thrown by
> the type initializer for System.Windows.Forms.Win32 --->
> System.NullReferenceException: Object reference not set to an
instance
> of an object
> in <0x748ed9> (wrapper managed-to-native)
> System.Windows.Forms.Win32:WineLoadLibrary (string)
> in <0x00004> (wrapper managed-to-native)
> System.Windows.Forms.Win32:WineLoadLibrary (string)
> in <0x00390> System.Windows.Forms.Win32:.cctor ()
> --- End of inner exception stack trace ---
> 
> in (unmanaged) System.Windows.Forms.Control:.cctor ()
> in <0x000f1> System.Windows.Forms.Control:.cctor ()
> --- End of inner exception stack trace ---
> 
> in (unmanaged) System.Windows.Forms.ScrollableControl:.ctor ()
> in <0x00011> System.Windows.Forms.ScrollableControl:.ctor ()
> in <0x0000a> System.Windows.Forms.ContainerControl:.ctor ()
> in <0x00016> System.Windows.Forms.Form:.ctor ()
> in <0x00083> FocusRemote.FocusRemote:.ctor ()
> in <0x0004a> (wrapper remoting-invoke-with-check)
> FocusRemote.FocusRemote:.ctor ()
> in <0x0001a> FocusRemote.FocusRemote:Main ()
> 
> [2]
> mcs/class/Managed.Windows.Forms$ make
> make all-local
> make[1]: Entering directory
> `/home/sjackman/src/mono/mcs/class/Managed.Windows.Forms'
> make[1]: *** No rule to make target
> `System.Windows.Forms/AccessibleEvents.cs', needed by
> `../../class/lib/default/System.Windows.Forms.dll'.  Stop.
> make[1]: Leaving directory
> `/home/sjackman/src/mono/mcs/class/Managed.Windows.Forms'
> make: *** [all.real] Error 2
> 
> > The problem with this specific issue (which is coming up in a cpl
> > places) is that people cvs up Managed-WinForms, or all of mcs, but
> leave
> > the mono stuff alone. When there is an addition (like this one)
that
> > requires updating both, they get issues.
> >
> > It seems like anyone using cvs should be somehow *forced* to do
make
> > bootstrap in mono/ and by default it should be more difficult
> (require
> > an option) to even build in the root mcs/ dir.
> >
> > That would cut down on a lot of these inane questions.
> >
> > --Todd
>
_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com 
http://lists.ximian.com/mailman/listinfo/mono-list