hi mike and thanx for the answer,
as far as I could see, mono have support for system.management.dll in the
extras package.
about the rest of the answer, well, it sounds like Chinese to me.
:teeth:
a little piece of code will do more help.
Mike Edenfield wrote:
On 4/13/2009 1:50 PM, tooty
Hi,
This should be already fixed in SVN as of r131472.
Still falling over dead on the PPC...
http://koji.fedoraproject.org/koji/getfile?taskID=1290915name=build.log
The problem seems to manifest if we disable linking against the static
libs on PPC and PPC64. Can someone have a look into
Hi guys:
I'm desperately trying to compile mono from last svn sources (Revision:
131666) and I'm getting:
...
Making all in docs
make[2]: Entering directory `/media/data/opt/monosvn/mono/docs'
cd . make -f docs.make topdir=../../mcs convert.exe
make[3]: Entering directory
Hi,
Building with --disable-static, in addition to producing a slower
runtime, is not tested by us so no wonder its not working. Why is this
needed on fedora ?
Zoltan
On Tue, Apr 14, 2009 at 8:59 AM, Paul p...@all-the-johnsons.co.uk wrote:
Hi,
This should be already
Hi all,
I would like to compile Mono 2.4 and run CC.NET on a redhat server.
I currently have glib-1.2.10-15 installed and it appears that 2.4 requires
glib 2.3.4.
Is there anyway of using Mono 2.4 on a server with only glib-1.2.10-15?
It may not be possible to get the 2.x version of glib
I'm reaching the conclusion that Mono v2.4 does not work on Solaris 10 SPARC
- this is based on both my own unsuccessful attempts to build and run it (or
debug it, for that matter), and on the non existence of reports on the web
indicating 2.4 success on the Solaris SPARC platform.
Giving up
John M wrote:
Hi all,
I would like to compile Mono 2.4 and run CC.NET on a redhat server.
I currently have glib-1.2.10-15 installed and it appears that 2.4 requires
glib 2.3.4.
Is there anyway of using Mono 2.4 on a server with only glib-1.2.10-15?
No.
It may not be possible to get
Hi guys:
Still having dificulties to build mono from svn sources, now I check
that the problem occur previous to my last post.., here the message that
I get:
make[9]: Entering directory `/media/data/opt/monosvn/mcs/class/I18N/Other'
MCS [net_2_0] I18N.Other.dll
**
Hi,
--
Paul F. Johnson
Lecturer in Chemistry, Biology and IT
FoundatiON Campus
Zoltan Varga var...@gmail.com 14/04/09 3:43 PM
Building with --disable-static, in addition to producing a slower
runtime, is not tested by us so no wonder its not working. Why is this
needed on fedora ?
Fedora
Hi,
--
Paul F. Johnson
Lecturer in Chemistry, Biology and IT
FoundatiON Campus
buhochil...@gmail.com buhochil...@gmail.com 14/04/09 3:36 PM
Hi guys:
I'm desperately trying to compile mono from last svn sources (Revision:
131666) and I'm getting:
Why not use the rpms for mono from rawhide
I currently have glib-1.2.10-15 installed and it appears that 2.4
requires
glib 2.3.4.
We do not test that, so I advise you against this.
You might be able to get it running if you force the build through,
just make sure at the end that `make check' works.
Alternatively, you can install
On 04/10/09 Mark Probst wrote:
The first patch moves the NumberFormatter out of Thread. As it is now,
the NumberFormatter is shared between AppDomains.
The second patch makes sure that an array obtained in another AppDomain
is not retained in the calling domain but copied.
This looks fine
Paul Johnson wrote:
Hi,
Hi Paul:
(Sorry for the top-posting don't know way my mail client errase the
previous messages when the mail is from you Paul...)
I'm trying to build from sources a parallel environment becouse the
rawhide mono/MD RPM's don't have the MD debugger addins witch are
Hi,
On Thu, 9 Apr 2009, Miguel de Icaza wrote:
Hello folks,
We were having this discussion a few months ago:
But remember that stackless python is, I think, more or less proper
implementation while Monoco is basically just a hack.
As of this week a variation of
Hi,
Statically linking the mono executable is mostly done to improve the speed
of thread-local
access, to ease debugging etc. Note that only libmono is linked statically
into the runtime,
the other dependencies like libglib are not. If fedora doesn't like static
libs, you can omit them from the
On Apr 14, 2009, at 3:02 PM, Martin Baulig wrote:
Still, I don't get mdb to properly run an executable yet. I believe
the problem may be that in OS X, i don't get any events from ptrace,
which seem to be used to initialize the debugger (like
PTRACE_EVENT_CLONE, etc..). When ptrace stops, it
Hi,
Statically linking the mono executable is mostly done to improve the
speed of thread-local
access, to ease debugging etc. Note that only libmono is linked
statically into the runtime,
the other dependencies like libglib are not. If fedora doesn't like
static libs, you can omit them
Exactly.
Zoltan
Not with you here. Are you saying that we need to enable statics while
building but don't need to include them in the final package?
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
___
On Tue, 14 Apr 2009 16:19:45 +0100
Paul Johnson pjohns...@uclan.ac.uk wrote:
Fedora ships with dynamic libs and frowns upon static ones (unless
they're really needed). I know I'll get asked this, but why are the
static libs needed and is it likely that x86/x86_64 will break in
future releases
Tomi Valkeinen wrote:
And I'm still of the opinnion that this stack-copying is more of an
interesting hack, than something people should really use =).
Is there a real cast-in-stone reason why a VM engine has to have a
contiguous stack at the
point where a hardware thread calls into the
Hello,
I know but the old status pages did not check IL for NIEs; they used the
presence of MonoTODO (and related) custom attribute to detect incomplete or
missing implementations. I actually prefer this approach.
I think I did a pass a few months ago where I moved
NotImplementedException
On Tue, 14 Apr 2009 11:47:36 -0400
buhochil...@gmail.com buhochil...@gmail.com wrote:
## DebuggerServer started
EXCEPTION: Mono.Debugger.TargetException: Unsupported `mono'
executable: /usr/bin/mono
I hadn't even read this email when I replied in the other thread, but
that is the exact
On 4/14/2009 11:47 AM, Martin Baulig wrote:
On Mon, 2009-04-13 at 10:45 -0400, Miguel de Icaza wrote:
* Has anyone actually done something like this and run into non-
obvious
problems? I'm most concerned that there are some gotchas in how Linux
manages memory, though if its just a matter of
Zoltan Varga vargaz at gmail.com writes:
Hi, Statically linking the mono executable is mostly done to improve the
speed of thread-localaccess, to ease debugging etc. Note that only libmono is
linked statically into the runtime,the other dependencies like libglib are not.
If fedora doesn't
Jonathan Soft yyellin at gmail.com writes:
I'm reaching the conclusion that Mono v2.4 does not work on Solaris 10 SPARC
- this is based on both my own unsuccessful attempts to build and run it (or
debug it, for that matter), and on the non existence of reports on the web
indicating 2.4
25 matches
Mail list logo
