Re: [Mono-dev] Unable to build mono-2.4RC2 on ppc
Hi, http://koji.fedoraproject.org/koji/getfile?taskID=1242258name=build.log It looks like there is a stack traceback with mcs Any advice would be appreciated. Looks like stack overflow, what is the stack size? Is this a 4K or 64K pagesize? Pagesize is 64k. I've not tried to build RC3 on it yet, but I know RC2 completely fails. What size is the mono runtime assuming or can I set it up for a particular size from the configure script? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 RC 3...
Hi, We've just released Mono 2.4 RC 3 today! Please help us out by giving it a try with your applications. Fails to build on my x86 Fedora box I'm getting Error: mini-trampolines.c:341:mono_magic_trampoline: assertion failed: (*vtable_slot). This is while building [net_2_0_bootstrap] System.Xml.dll Stacktrace looks to be borking on Mono.CSharp.TypeOf.DoResolveBase() TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 RC 3...
I still want https://bugzilla.novell.com/show_bug.cgi?id=467834 to be fixed. Despite Zoltan's comments this is a regression since mono 2.0.1 2009/3/18 Paul p...@all-the-johnsons.co.uk: Hi, We've just released Mono 2.4 RC 3 today! Please help us out by giving it a try with your applications. Fails to build on my x86 Fedora box I'm getting Error: mini-trampolines.c:341:mono_magic_trampoline: assertion failed: (*vtable_slot). This is while building [net_2_0_bootstrap] System.Xml.dll Stacktrace looks to be borking on Mono.CSharp.TypeOf.DoResolveBase() TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! ___ 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] [Mono-olive] Bugs + fixes for System.IO.Packaging
Hi, I've fixed a number of the issues you've mentioned. The ones I haven't applied fixes for are listed below with explanations: Resolved issues: 1, 2, 3, 4, 5, 9, 10, 11, 12 Unresolved issues: 6, 7, 8 6) (Package.LoadRelationships - operation not valid) I can't replicate this issue. Can you verify that it's still there and if so create a small testcase to demonstrate the issue 7) Duplicate [Content_Types].xml I didn't apply the fix because this PackagePart should never be in the 'Parts' dictionary. If you are seeing it in the dictionary, could you create a testcase which replicates the issue so that I can fix it. 8) content type is always application/xml I have an NUnit test, PackagePartTest.CheckPartProperties () which tests content types are loaded correctly and the test is passing. Can you supply a testcase which demonstrates the issue? I'm just going to deal with your newer emails now. Alan. p.s. Thanks for the very detailed bug report. It was very easy to derive NUnit tests from your descriptions to prevent these issues from surfacing again. On Mon, Mar 16, 2009 at 10:52 AM, Alan McGovern alan.mcgov...@gmail.comwrote: Hi, Great stuff! I'm going to review this today and commit it if all goes well. If you have any more bugs, just fire an email to the mono-devel list (CC'ed) in case I'm not around to deal with them. Alan. On Sun, Mar 15, 2009 at 12:22 AM, Yves Dhondt yves.dho...@gmail.comwrote: Hello, I worked a bit more on the thing and came up with several more bugs and fixes. I extended my original document to include those as well. With the current set of fixes, it is possible to open an existing Word 2007/2008 document with ReadWrite permission and close it again without corrupting it. I have not tested it on other types of packages (Excel, Powerpoint) but they should work as well. Regards, Yves On Sat, Mar 14, 2009 at 12:56 PM, Yves Dhondt yves.dho...@gmail.comwrote: Hello, This is probably not the best way of bug reporting but I could not find any track on bugzilla for olive to submit this under. The included pdf contains the description and possible fixes I came across when trying to use the olive WindowsBase.dll. Note that I only fixed those things to work for my needs and in some cases, more in-depth testing might be required (especially in PackUriHelper.ResolvePartUri). If you have any questions, feel free to contact me. Regards, Yves ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in Package.cs due to update in PackageProperties.cs (System.IO.Packaging / Olive)
Should be fixed properly in SVN. Let me know if it's not.
Alan.
On Mon, Mar 16, 2009 at 7:36 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Hello,
Revision 129478 fixes the NSPackageProperties string to correctly load
PackageProperties. However, the string is also used by Package.cs for
LoadRelationships. The change has broken that function as the string
used to be correct there.
In Package.LoadRelationships, the line:
if (r.RelationshipType ==
System.IO.Packaging.PackageProperties.NSPackageProperties) {
should become:
if (r.RelationshipType ==
http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties
)
{
Regards,
Yves
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for ZipPackagePart.GetStreamCore in System.IO.Packaging (olive)
Working on this one now.
Thanks!
Alan.
On Mon, Mar 16, 2009 at 7:21 PM, Yves Dhondt yves.dho...@gmail.com wrote:
Issue:
---
ZipPackagePart.GetStreamCore in System.IO.Packaging does not handle
Filemode mode input parameter (correctly).
Test program (requires an existing openxml document, for example
test.docx as input):
---
I'm not that good with unit testing, but the following code should be
easily translated into 4 tests.
using System;
using System.IO;
using System.IO.Packaging;
namespace MonoOpenXmlExperiment
{
class Program
{
static void Main(string[] args)
{
// Warning do this with a document which can be damaged!!!
Package pack = Package.Open(args[0]);
PackagePart part = pack.CreatePart(new Uri(/somepart.xml,
UriKind.Relative), application/xml);
try
{
Stream s2 = part.GetStream(FileMode.CreateNew, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as CreateNew is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
try
{
Stream s3 = part.GetStream(FileMode.Truncate, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as Truncate is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
try
{
Stream s4 = part.GetStream(FileMode.Append, FileAccess.Write);
}
catch (Exception ex)
{
// An ArgumentException should be throw as Append is an
unsupported mode.
Console.WriteLine(Expected ArgumentException, got {0}.,
ex.GetType().ToString());
}
Stream s = part.GetStream(FileMode.OpenOrCreate, FileAccess.Write);
StreamWriter sw = new StreamWriter(s);
sw.Write(testaaa/test);
sw.Flush();
Stream s5 = part.GetStream(FileMode.Create, FileAccess.ReadWrite);
StreamWriter sw2 = new StreamWriter(s5);
sw2.Write(testbbb/test);
sw2.Flush();
// Verify that the part got overwritten correctly.
Stream s6 = part.GetStream();
StreamReader sr = new StreamReader(s6);
Console.WriteLine(Expected testbbb/test, got {0}.,
sr.ReadToEnd());
pack.Close();
}
}
}
Expected output:
Expected ArgumentException, got System.ArgumentException.
Expected ArgumentException, got System.ArgumentException.
Expected ArgumentException, got System.ArgumentException.
Expected testbbb/test, got testbbb/test.
Output currently given by mono:
-
Expected testbbb/test, got testbbb/test.
Remarks:
-
The last test is especially important as it indicates that a create
would only overwrite part of stream.
Solution:
Replace function by:
protected override Stream GetStreamCore (FileMode mode, FileAccess access)
{
MemoryStream stream;
switch (mode)
{
case FileMode.CreateNew:
throw new ArgumentException(FileMode not supported,
CreateNew);
case FileMode.Truncate:
throw new ArgumentException(FileMode not supported,
Truncate);
case FileMode.Append:
throw new ArgumentException(FileMode not supported, Append);
case FileMode.Open:
if (Package.PartStreams.TryGetValue(Uri, out stream)) {
return new ZipPartStream(Package, stream, access);
}
else {
throw new IOException(); // Verify that this is the
correct exception.
}
case FileMode.OpenOrCreate:
case FileMode.Create:
// Check if a stream is already loaded. If not, load it or
create an empty one.
if (!Package.PartStreams.TryGetValue(Uri, out stream)) {
stream = new MemoryStream();
try
{
using (UnzipArchive archive = new
UnzipArchive(Package.PackageStream))
{
foreach (string file in archive.GetFiles())
{
if (file != Uri.ToString().Substring(1))
continue;
using (Stream archiveStream = archive.GetStream(file))
{
int read = 0;
byte[] buffer = new
byte[Math.Min(archiveStream.Length, 2 * 1024)];
while ((read = archiveStream.Read(buffer, 0,
buffer.Length)) != 0)
stream.Write(buffer, 0, read);
}
}
}
}
catch
{
// The zipfile is invalid, so just create the file
// as if it didn't exist
stream.SetLength(0);
}
[Mono-dev] no multicast addresses returned from IPInterfaceProperties
It looks like the NetworkInterface class uses getifaddrs(3) to fetch all addresses associated with an interface. This list is then used to fill in the multicast addresses returned from the IPInterfaceProperes.MulticastAddresses property. This doesn't appear to work and I don't think getifaddrs returns any multicast addresses. I wanted to confirm this with someone else before filing a bug. It looks like the appropriate thing to do on Linux is to parse /proc/net/igmp. I'm not sure what the equivalent on windows would be. -jake IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Updating mono/monodevelop from fedora 10 repos problems...
Hi: Trying to update monodevelop on fedora 10 using fedora 11 rawhide repos I get this kind of errors: file /usr/bin/mod from install of mono-core-2.4-9.RC1.fc11.i586 conflicts with file from package monodoc-2.0-5.fc10.i386 Also installing dependencies this kind of errors...: Updating : gtk-sharp2 1/17 Error unpacking rpm package gtk-sharp2-2.12.7-4.fc11.i586 error: unpacking of archive failed on file /usr/lib/libatksharpglue-2.so;49c107f3: cpio: MD5 sum mismatch But the more critical thing is that yum also try to update glib, due to the above things the transaction fail, glib was removed from my system, so now fedora 10 goes bye bye , any ideas to solve that without reinstalling the hole system?? Thanks Mauricio ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Updating mono/monodevelop from fedora 10 repos problems...
Hi, -- Paul F. Johnson Lecturer in Science and IT FoundatiONCampus buhochil...@gmail.com buhochil...@gmail.com 18/03/2009 16:32 ( mailto:buhochil...@gmail.com ) Trying to update monodevelop on fedora 10 using fedora 11 rawhide repos I get this kind of errors: file /usr/bin/mod from install of mono-core-2.4-9.RC1.fc11.i586 conflicts with file from package monodoc-2.0-5.fc10.i386 Also installing dependencies this kind of errors...: Updating : gtk-sharp2 1/17 Error unpacking rpm package gtk-sharp2-2.12.7-4.fc11.i586 error: unpacking of archive failed on file /usr/lib/libatksharpglue-2.so;49c107f3: cpio: MD5 sum mismatch monodoc will conflict as there is a problem with it being removed from koji currently. I'm not sure why gtk-sharp2 is failing, all I can think of is that there is some form of interuption on your connection which corrupted the file. As for everything else, well there isn't much that can be done. What may be of more use is to download the mono family srpms from rawhide and build them from scratch. Just a suggestion TTFN Paul ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Updating mono/monodevelop from fedora 10 repos problems...
2009/3/18 Paul Johnson pjohns...@uclan.ac.uk: Hi, -- Paul F. Johnson Lecturer in Science and IT FoundatiONCampus buhochil...@gmail.com buhochil...@gmail.com 18/03/2009 16:32 Trying to update monodevelop on fedora 10 using fedora 11 rawhide repos I get this kind of errors: file /usr/bin/mod from install of mono-core-2.4-9.RC1.fc11.i586 conflicts with file from package monodoc-2.0-5.fc10.i386 Also installing dependencies this kind of errors...: Updating : gtk-sharp2 1/17 Error unpacking rpm package gtk-sharp2-2.12.7-4.fc11.i586 error: unpacking of archive failed on file /usr/lib/libatksharpglue-2.so;49c107f3: cpio: MD5 sum mismatch I think you might need gtk-sharp2-2.12.8. I'm not sure if that is in koji or not? Stephen monodoc will conflict as there is a problem with it being removed from koji currently. I'm not sure why gtk-sharp2 is failing, all I can think of is that there is some form of interuption on your connection which corrupted the file. As for everything else, well there isn't much that can be done. What may be of more use is to download the mono family srpms from rawhide and build them from scratch. Just a suggestion TTFN Paul ___ 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-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
In short, it's not working for me but I'm willing to keep trying and document my experiences if I can get some help from the Mono developer community. I apologize for the lengthy post but I figured that I might as well be thorough. Background: I have been wrestling with trying to compile various versions of Mono. After a good deal of trouble, I managed to build v2.0.1 on my Solaris 10 SPARCv9 machine. It has issues (i.e. bugs in Mono), but I think the build itself was successful. I believe many of my issues have been fixed in later Mono fixes, but thus far I have been unable to build Mono v2.2, v126637, and v2.4 RC2. I'm hoping to be able to utilize v2.4 when it's released but if I can't compile the RC2, obviously I'll have an issue when v2.4 becomes official. If it's a bug with me, I could certainly use some help. If it's a bug in Mono, I need some help finding it so hopefully it can be fixed before v2.4 is released later this month. I hope to document all the issues and fixes that I've encountered thus far - the documentation for building Mono on Solaris is very scattered, but I'd hate to conclude mine with but in the end it doesn't work. Problem: 'Configure' succeeds and 'make' gets all the way to where it compiles System.dll (with warning 'System.dll build without parts that don't depend on: System.Xml.dll'. I then get MCS [basic] System.dll, and then the annoying GC Warning: Large stack limit(...): only scanning 8 MB warning. It's followed by a 'Compilation succeeded - 13 warnings(s)' message which tells me that it finished System.dll. It then tries working on System.Xml.dll after doing what looks like some lexer tree reductions (messages like 3 rules never reduced, 1 shift-reduce conflict, etc) and then the MCS[basic] System.Xml.dll message. This is the last thing I see. I can wait for over 16 hours and nothing happens, other than prstat reporting that 'mono' has used 16+ hours of CPU time. It gives an '.../class/lib/basic/System.Xml.dll] Error 130' message after I kill it but that is just from me interrupting it. For some reason, the build process is either unable to compile System.Xml.dll, or it runs something that hangs. I don't see any 'compilation succeeded' message like with System.dll so I assume it's the former. But it was able to compile System.dll so why can't it compile System.Xml.dll? As what may be an important side-note, my previous brick wall was with build/deps/basic-profile-check.exe. I was able to get past this issue but I think it's probably the same problem as above, or at least related, so I thought it best to mention it: 'Configure' succeeds and 'make' gets all the way to where it enters the mcs directory. I get the The compiler 'mcs' doesn't appear to be usable. Trying the 'monolite' directory. message and then it seems to re-try compiling and/or running basic-profile-check.exe and I've waiting over 16 hours and nothing else happens - it's hung. When I kill it, it says [build/deps/basic-profile-check.exe] Error 127, and then gives an Error 130 but that's just from my interrupting it. For some reason, the build process is either unable to compile basic-profile-check.exe or when it runs it, it hangs. My guess is the former. Either way, if I add my Mono v2.0.1 bin directory to my path, it's able to get past this problem - but then hangs on System.Xml.dll per above. What Didn't Work: First, note that my system does not have access to the Internet. Things like 'make get-mono-latest' don't work for me. Regardless, I now have a rather complete GNU bin directory that I've compiled myself, including GCC v3.4.3, TAR v1.21, ar, as, grep, ranlib, strip, ld, etc. I've renamed the 'mcs' file native to Solaris to something else. I've replaced the -mt option in gthread-2.0.pc with -D_REENTRANT. I'm including a copy of libgdiplus v2.4 that I built, although I understand that's just needed for System.Drawing to work. I've tried including and not including my v2.0.1 bin and lib in my environment to no avail. I've tried various combinations of configure options such as these: --disable-dtrace --with-gc=none --with-sigaltstack=no --with-ikvm-native=no --disable-mcs-build. The summary at the end of Configure confirms that these work (i.e. I was previously using signaltstack=no...), and TLS: pthread, which I believe was auto-detected correctly. I'm using ulimit -Hs 10240 now but it doesn't seem to be doing anything. I've tried using monolite from mono-project.org and adding that to my path. I've even tried letting the _tmpinst directory get created and then editing the scripts in it to point to my Mono v2.0.1 files instead of the build ones. I have read that others have succeeded on Solaris 10 SPARC, so thus far I've avoid making any code changes to the source, but as of this post that's my next step as I can't think of any other avenues. Nothing seems to let me get past this problem - any ideas? -- View this message in context:
[Mono-dev] mono-profiler-logging.c:4294: error: 'struct stat' has no member named 'st_mtim'
I am trying to build mono-2.2 on my linux box. I receive the following error while doing make mono-profiler-logging.c: In function 'profiler_heap_shot_process_command_file': mono-profiler-logging.c:4294: error: 'struct stat' has no member named 'st_mtim' make[3]: *** [mono-profiler-logging.lo] Error 1 my machine info $ uname -a Linux mymachine 2.4.20-28.7 #1 Thu Dec 18 11:31:59 EST 2003 i686 unknown I have gcc-4.1.2 and glib2-2.16.4. -- View this message in context: http://www.nabble.com/mono-profiler-logging.c%3A4294%3A-error%3A-%27struct-stat%27-has-no-member-named-%27st_mtim%27-tp22587507p22587507.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch: Ternary ops in mini and general ATOMIC_CAS
I quite like this patch, it removes more code than it adds back. The results
should look clear
and if we end wishing optimizing a spot we can trade the loop for an inlined
function or macro. [1]
But there are a few things that I dislike about this patch.
--- a/mono/mini/cfold.c
+++ b/mono/mini/cfold.c
@@ -58,13 +58,18 @@ mono_is_power_of_two (guint32 val)
res = (cast)arg1-inst_c0 op (cast)arg2-inst_c0;\
break; \
+#define MONO_INST_NULLIFY_SREGS(dest) do {\
+(dest)-sreg1 = (dest)-sreg2 = (dest)-sreg3 = -1;\
+} while (0)
+
#undef MONO_INST_NEW
#define MONO_INST_NEW(cfg,dest,op) do {\
(dest) = mono_mempool_alloc ((cfg)-mempool, sizeof (MonoInst));
\
(dest)-inst_p0 = (dest)-inst_p1 = (dest)-next = NULL; \
(dest)-opcode = (op);\
(dest)-flags = 0; \
-(dest)-dreg = (dest)-sreg1 = (dest)-sreg2 = -1; \
+(dest)-dreg = -1;\
+MONO_INST_NULLIFY_SREGS ((dest));\
} while (0)
This is pure code duplication, kill it instead of patching.
@@ -138,6 +142,15 @@ ins_info[] = {
#include mini-ops.h
};
#undef MINI_OP
+#undef MINI_OP3
+
+#define MINI_OP(a,b,dest,src1,src2) -1,
+#define MINI_OP3(a,b,dest,src1,src2,src3) -1,
+gint8 ins_sreg_counts[] = {
+#include mini-ops.h
+};
+#undef MINI_OP
+#undef MINI_OP3
This information can be calculated at compile time. All we get from running
mini_init_op_sreg_counts
is an increased private RSS with no advantage. This information should be
packaged in the ins_info array.
@@ -437,7 +450,7 @@ struct MonoInst {
guint8 flags : 5;
/* used by the register allocator */
-gint32 dreg, sreg1, sreg2;
+gint32 dreg, sreg1, sreg2, sreg3;
This change increases the JIT working set significantly. Have you thought
about doing something like
struct MonoCallInst?
It would allow us to have 3 sregs and only pay the size price when needed.
It would be trivial to have
a function to detect such instructions by expanding mini-ops.h to avoid
hitting the ins_info array.
Besides that, I'm eager to have this patch in so I can exploit it on
Mono.Simd :)
[1] Doing something like like:
for (i = 0; i sreg_count (ins); ++i)
z
to
static inline foo() { z } //OR
#define FOO() do { z; } while (0)
if (has_sreg1)
foo ();
if (has_sreg2)
foo ();
if (unlikely (has_sreg3)
foo ();
2009/3/13 Mark Probst mark.pro...@gmail.com
On Mon, Feb 23, 2009 at 10:10 PM, Zoltan Varga var...@gmail.com wrote:
All this to add support for exactly one rarely used instruction, CAS.
As per Paolo's request I timed a --compile-all of
System.Windows.Forms.dll (which I chose instead of mscorlib.dll
because it's larger) with and without the patch. It turns out with
the patch we're about 10% slower. With the attached revised patch,
which uses macros for all the getter functions, the difference is
barely 3% (2.3166s vs 2.2522s, on x86).
Mark
___
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] mono-profiler-logging.c:4294: error: 'struct stat' has no member named 'st_mtim'
If I configure it with /configure --enable-minimal=profiler then I get . . . . *** The compiler 'mcs' doesn't appear to be usable. *** Trying the 'monolite' directory. make[7]: Entering directory `/dev/mono-2.2/mono-2.2/mcs' ** ** ERROR:(mini-exceptions.c:1134):mono_setup_altstack: assertion failed: (staddr) make[8]: *** [build/deps/basic-profile-check.exe] Aborted make[8]: Entering directory `/dev/mono-2.2/mono-2.2/mcs' *** The contents of your 'monolite' directory may be out-of-date *** You may want to try 'make get-monolite-latest' make[8]: *** [do-profile-check-monolite] Error 1 . . . . blair_boost wrote: I am trying to build mono-2.2 on my linux box. I receive the following error while doing make mono-profiler-logging.c: In function 'profiler_heap_shot_process_command_file': mono-profiler-logging.c:4294: error: 'struct stat' has no member named 'st_mtim' make[3]: *** [mono-profiler-logging.lo] Error 1 my machine info $ uname -a Linux mymachine 2.4.20-28.7 #1 Thu Dec 18 11:31:59 EST 2003 i686 unknown I have gcc-4.1.2 and glib2-2.16.4. -- View this message in context: http://www.nabble.com/mono-profiler-logging.c%3A4294%3A-error%3A-%27struct-stat%27-has-no-member-named-%27st_mtim%27-tp22587507p22588968.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
