[Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5
I have an R package with embedded Mono, on Linux, that is working on Mono 3.12.x series but broken since Mono 4.0.x. Crashes with: Assertion at sgen-alloc.c:774, condition `tlab_next_addr_offset != -1' not met Repro and details at https://github.com/jmp75/rClr/issues/7, but optional for this present question. What I am after is to step in debug mode through Mono, to diagnose and hopefully figure out a fix, but could not find a procedure to: * build/install mono from source (I know that) but with debug symbols * If the above is done, can I use MonoDevelop or other graphical front-end to attach to the process with embedded Mono and step through code with GDB. I can already attach MonoDevelop to the R process and catch the crash, but the call stack is devoid of info and reference to the source code (presumably lacking the former debug symbols?) Any advice on how to go about it is welcome. I hope we can do better than command line gdb. Cheers ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5
I am trying to debug C code, mostly to step through the mono runtime itself. The issue seems to arise really quickly and I do not expect c# code (mine or the framework's) to be at fault here. That said, I would not at all refuse a howto guide for mixed mode (C and C#) debugging on Linux (not possible so far as I know). I may try to give a try on Windows with Visual Studio, but as a fallback option as this issue may not be reproducible on it anyway. From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Jonathan Mitchell [jonat...@mugginsoft.com] Sent: Tuesday, August 04, 2015 7:34 PM To: Mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5 On 4 Aug 2015, at 08:26, jean-michel.perr...@csiro.au wrote: * build/install mono from source (I know that) but with debug symbols I would second this. * If the above is done, can I use MonoDevelop or other graphical front-end to attach to the process with embedded Mono and step through code with GDB. I can already attach MonoDevelop to the R process and catch the crash, but the call stack is devoid of info and reference to the source code (presumably lacking the former debug symbols?) Are you trying to debug the managed code or the embedded C API? Jonathan ___ 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] Do we need to maintain the csproj files?
The csproj files can be generated by a C# program under msvc/scripts. The resulting csproj are pushed to github from time to time, but you can generate them yourself if need be. I worked on this a couple of years ago, and I think Miguel did further work in May 2014. From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Martin Thwaites [monofo...@my2cents.co.uk] Sent: Sunday, October 19, 2014 6:59 AM To: mono-devel-list Subject: [Mono-dev] Do we need to maintain the csproj files? Hi all, I'm wondering if, when adding new classes, we need to also add the file to the relevant .csproj file as well as the .sources files? I'm not sure what state they're in, but I am using them myself to develop with, so it would be useful if that was the rule. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Latest source - build yields Could not load type 'Mono.CSharp.CommandLineParser' (17170)
Hi,
Just reporting I got similar issues compiling from the 3.8.0 tarball, on a
CentOS system (with or without a previous working mono runtime already
available). Not quite the message in that bug report, but failing to find a
working gmcs (sorry cannot access the message details right now), with or
without the make with EXTERNAL_MCS workaround. Compiling from the 3.2.8
tarball works fine.
Curiously, no problem at all encountered with the same tarball on a Debian
unstable box.
J-M
From: mono-devel-list-boun...@lists.ximian.com
[mono-devel-list-boun...@lists.ximian.com] on behalf of Chris Tacke
[cta...@opennetcf.com]
Sent: Saturday, September 13, 2014 9:09 AM
To: mono-devel-list
Subject: [Mono-dev] Latest source - build yields Could not load type
'Mono.CSharp.CommandLineParser' (17170)
Bug 17170 is marked as RESOLVED/FIXED but it's still occurring with a git
pull of the latest as of this morning:
https://bugzilla.xamarin.com/show_bug.cgi?id=17170
The proposed workaround of
make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe
After getting monolite and before running make does work, but a straight
make fails with Could not load type 'Mono.CSharp.CommandLineParser'
-Chris
___
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] Editing mono in IDE?
The solutions under msvc/script are (were) generated by parsing the Makefiles. Work done ~2 years ago was to make the resulting sln/csproj files more navigable (F12 and so on) from visual studio. While attempted, building to completion a substantial subset of the c# part of Mono was (is?) in the too hard basket. Besides, VS ddd (does?) not let you easily replace its GAC mscorlib by another one... Miguel de Icaza, and possibly others I overlook, have recently worked on the Makefile mono build process and genproj.cs (https://github.com/mono/mono/blob/master/msvc/scripts/README). Some workarounds I needed to do a couple of years ago seem no longer necessary. From memory genproj.exe had (probably still has) some options to limit the resulting solutions to a smaller size (e.g. include all the System.* projects and their dependencies). This may be a basis to generate a small-ish solution for a particular part of the Mono stack. Yes, by default the full 4.5 solution is otherwise huge. Christian, if you have not already done so, you should search for discussion threads popping every few months on how to get set up / operate to work on Mono itself. J-M From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Atsushi Eno [atsushi...@veritas-vos-liberabit.com] Sent: Sunday, June 08, 2014 1:30 PM To: Hüning, Christian; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Editing mono in IDE? You would most likely like to create your own solution from existing sources... These days I've been working on Microsoft.Build.dll these days with my own solution and projects [*1] because the centralized msvc/scripts/net_4_5.sln is quite useless (too big). And I can't think of any generalized way of generating appropriate set of projects for each classlib assembly. [*1] https://github.com/atsushieno/mono/blob/msbuilddll2/msvc/scripts/net_4_5_msbuild.sln Atsushi Eno Hüning, Christian wrote: Hi, I wondered if there is a way to efficiently and effectively develop mono with an IDE like Xamarin Studio / Visual Studio? I couldn’t find a central .sln file or something (did find quite a lot .sln files, but none that seemed to be THE solution file, if there is any). Is that even intended? Cheers Christian ___ 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-dev] Repeat builds of core assemblies
Sorry, somehow I misread who was saying what; I should have addressed the mail primarily to Miguel. Happy to provide further information. I think Marek Saraf is the person that merged these updates in 2012 to the VS build process. For reference (won't provide much additional material) I have a stale branch at https://github.com/jmp75/mono/tree/msvc_build_20130604 I intended to use for better documentation. Let me know if I can contribute something. Cheers. From: Perraud, Jean-Michel (CLW, Black Mountain) Sent: Wednesday, April 23, 2014 10:23 AM To: Michael Franz; Miguel de Icaza Cc: mono-devel Subject: RE: [Mono-dev] Repeat builds of core assemblies Michael, how are you fitting msbuild in the build process? Just to confirm if you using the generation of csharp project files and solutions for visual studio? A couple of years back I worked on unwinding the circular build dependencies to build the assemblies from VS. As I recall, even then I needed to disable the parallel build option in VS to avoid some issues. The resulting build process had a few warts left, but I could built most of it from VS fine without nightmare dll swapping. If you are approaching the build another way, I'd be interested to know how. You'll find emails on it in the mono-devel-list archives (http://lists.ximian.com/pipermail/mono-devel-list/). I cannot seem to access the archives just now, but a google search with for instance the terms build visual studio site:lists.ximian.com/pipermail/mono-devel-list/ will give you prior information. I think there was a thread a few months back of people interested in contributing to Mono from Visual Studio, which may provide some help. I'll see if I can dig this up. I started a branch to document the build process using the VS toolchains, but could not find the time to follow up. Cheers, J-M From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Michael Franz [mvfr...@gmail.com] Sent: Wednesday, April 23, 2014 9:46 AM To: Miguel de Icaza Cc: mono-devel Subject: Re: [Mono-dev] Repeat builds of core assemblies On Tue, Apr 22, 2014 at 3:53 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, I was looking at making the MSBuild system work, and during the process I have encountered a few problems that we have in our existing build system that are problematic. The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies. So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration. Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on. snip Is this a Microsoft circular dependency or a Mono implementation issue? Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Repeat builds of core assemblies
Michael, how are you fitting msbuild in the build process? Just to confirm if you using the generation of csharp project files and solutions for visual studio? A couple of years back I worked on unwinding the circular build dependencies to build the assemblies from VS. As I recall, even then I needed to disable the parallel build option in VS to avoid some issues. The resulting build process had a few warts left, but I could built most of it from VS fine without nightmare dll swapping. If you are approaching the build another way, I'd be interested to know how. You'll find emails on it in the mono-devel-list archives (http://lists.ximian.com/pipermail/mono-devel-list/). I cannot seem to access the archives just now, but a google search with for instance the terms build visual studio site:lists.ximian.com/pipermail/mono-devel-list/ will give you prior information. I think there was a thread a few months back of people interested in contributing to Mono from Visual Studio, which may provide some help. I'll see if I can dig this up. I started a branch to document the build process using the VS toolchains, but could not find the time to follow up. Cheers, J-M From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Michael Franz [mvfr...@gmail.com] Sent: Wednesday, April 23, 2014 9:46 AM To: Miguel de Icaza Cc: mono-devel Subject: Re: [Mono-dev] Repeat builds of core assemblies On Tue, Apr 22, 2014 at 3:53 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, I was looking at making the MSBuild system work, and during the process I have encountered a few problems that we have in our existing build system that are problematic. The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies. So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration. Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on. snip Is this a Microsoft circular dependency or a Mono implementation issue? Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 3.2.8 fails to compile from source
I can report I could compile from the git tag 3.2.8 and the tarball, on a Debian unstable x64, doing a make while a mono 3.2.3 was installed. I had messed up my local 3.2.3 and needed to rebuild/reinstall it to successfully compile 3.2.8. I also had some difficulties on CentOS starting from the tarball, which I eventually overcame with a few attempts, unfortunately cannot give reproducible steps since this was a trial and error affair. I did have issues recently with MCS [net_2_0] mscorlib.dll and 3.2.7, so your persistence may pay off. All I can advise is for you to have a recent (3.2.3 or newer) Mono installed prior to building 3.2.8. Cheers -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Daniel Isenmann Sent: Monday, 24 February 2014 7:40 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Mono 3.2.8 fails to compile from source Hi, mono 3.2.8 fails to compile from source tarball (at least on a x86_64, don't tested it on a i686 system). Following error appears: System.IO.MemoryMappedFiles/MemoryMappedFile.cs(442,8): warning CS0414: The private field `System.IO.MemoryMappedFiles.MemoryMappedFile.fileCapacity' is assigned but its value is never used Compilation succeeded - 10 warning(s) MCS [build] mcs.exe AOT [build] mscorlib.dll.so AOT [build] mcs.exe.so MCS [build] gacutil.exe MCS [build] sn.exe MCS [build] culevel.exe CompileUplevel.cs(943,34): warning CS0618: `System.CodeDom.Compiler.CodeDomProvider.CreateGenerator()' is obsolete: `ICodeGenerator is obsolete' Compilation succeeded - 1 warning(s) mkdir -p -- ../../class/lib/net_2_0/tmp/ MCS [net_2_0] mscorlib.dll Unhandled Exception: Nested exception detected. Original Exception: at System.NumberFormatter.GetInstance () 0x00029 at System.NumberFormatter.NumberToString (string,int,System.IFormatProvider) 0x00016 at int.ToString (string,System.IFormatProvider) 0x00027 at string.FormatHelper (System.Text.StringBuilder,System.IFormatProvider,string,object[]) 0x00539 at System.Text.StringBuilder.AppendFormat (System.IFormatProvider,string,object[]) 0x0002e at System.Text.StringBuilder.AppendFormat (string,object,object,object) 0x000a2 at Mono.CSharp.ReportPrinter.Print (Mono.CSharp.AbstractMessage,System.IO.TextWriter,bool) 0x00150 at Mono.CSharp.StreamReportPrinter.Print (Mono.CSharp.AbstractMessage,bool) 0x00028 at Mono.CSharp.Report.Error (int,Mono.CSharp.Location,string) 0x0008e at Mono.CSharp.Report.Error (int,Mono.CSharp.Location,string,string) 0x00040 at Mono.CSharp.Report.Error (int,string,string) 0x00046 at Mono.CSharp.CommandLineParser.ParseOption (string,string[],Mono.CSharp.CompilerSettings) 0x01fcb at Mono.CSharp.CommandLineParser.ParseArguments (Mono.CSharp.CompilerSettings,string[]) 0x0035c at Mono.CSharp.CommandLineParser.ParseArguments (string[]) 0x00040 at Mono.CSharp.Driver.Main (string[]) 0x00081 Nested exception:at System.NumberFormatter.GetInstance () 0x00029 at System.NumberFormatter.NumberToString (string,int,System.IFormatProvider) 0x00016 at int.ToString (string,System.IFormatProvider) 0x00027 at string.FormatHelper (System.Text.StringBuilder,System.IFormatProvider,string,object[]) 0x00539 at System.Text.StringBuilder.AppendFormat (System.IFormatProvider,string,object[]) 0x0002e at System.Text.StringBuilder.AppendFormat (string,object) 0x00052 at System.Exception.AddFrames (System.Text.StringBuilder,string,string,System.Diagnostics.StackTrace) 0x001e9 at System.Exception.get_StackTrace () 0x0016b at System.Exception.ToString () 0x0010d [ERROR] FATAL UNHANDLED EXCEPTION: Nested exception detected. Original Exception: at System.NumberFormatter.GetInstance () 0x00029 at System.NumberFormatter.NumberToString (string,int,System.IFormatProvider) 0x00016 at int.ToString (string,System.IFormatProvider) 0x00027 at string.FormatHelper (System.Text.StringBuilder,System.IFormatProvider,string,object[]) 0x00539 at System.Text.StringBuilder.AppendFormat (System.IFormatProvider,string,object[]) 0x0002e at System.Text.StringBuilder.AppendFormat (string,object,object,object) 0x000a2 at Mono.CSharp.ReportPrinter.Print (Mono.CSharp.AbstractMessage,System.IO.TextWriter,bool) 0x00150 at Mono.CSharp.StreamReportPrinter.Print (Mono.CSharp.AbstractMessage,bool) 0x00028 at Mono.CSharp.Report.Error (int,Mono.CSharp.Location,string) 0x0008e at Mono.CSharp.Report.Error (int,Mono.CSharp.Location,string,string) 0x00040 at Mono.CSharp.Report.Error (int,string,string) 0x00046 at Mono.CSharp.CommandLineParser.ParseOption (string,string[],Mono.CSharp.CompilerSettings) 0x01fcb at Mono.CSharp.CommandLineParser.ParseArguments (Mono.CSharp.CompilerSettings,string[]) 0x0035c at Mono.CSharp.CommandLineParser.ParseArguments (string[]) 0x00040 at Mono.CSharp.Driver.Main (string[]) 0x00081 Nested exception:at System.NumberFormatter.GetInstance () 0x00029 at System.NumberFormatter.NumberToString
[Mono-dev] Failure to compile Mono 3.2.7-branch from source
Hi, I am trying to test an app on Mono 3.2.7, but cannot seem to get it to build properly. I can check out the 3.2.3 branch, and build/install it bootstrapped with the prepackaged 3.0.6, but whether I use 3.2.3 or 3.0.6 as a bootstrap the build of 3.2.7 fails. If anyone has a hunch or advice. Cheers Repro information: Linux 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux (Debian Unstable, just updated all packages) Mono JIT compiler version 3.2.3 (mono-3.2.3-branch/4d8ba16 Tuesday 18 February 15:23:35 EST 2014) Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:sgen git checkout mono-3.2.7-branch git pull ./autogen.sh --prefix=/usr/local make MCS [build] mscorlib.dll Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x001f7 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: /home/xyz/src/mono/mono/mini/mono() [0x4b6398] /home/xyz/src/mono/mono/mini/mono() [0x50d81b] /home/xyz/src/mono/mono/mini/mono() [0x423ae2] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf210) [0x2b284160e210] /lib/x86_64-linux-gnu/libpthread.so.0(pthread_join+0x24) [0x2b2841607f64] /home/xyz/src/mono/mono/mini/mono() [0x5a9e84] /home/xyz/src/mono/mono/mini/mono(mono_runtime_cleanup+0xe) [0x5a1d5e] /home/xyz/src/mono/mono/mini/mono() [0x41b6b6] /home/xyz/src/mono/mono/mini/mono() [0x53d4db] [0x41aed82d] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Getting started on mono sources
Hi Edward, At least a couple of people including myself have an interest in recommended dev env to work on Mono itself ( http://lists.ximian.com/pipermail/mono-devel-list/2013-July/040638.html). A Howto on recommended setup for Mono contributions would save a fair bit of time and hassle for contributors, but I have not heard of such a document. You should find a Visual Studio solution under /mono/msvc/scripts. The Readme has some instructions as to how to re-generate solution and project files if you so wish. A couple of years ago I updated the code that generates VS project and solution files, with the intent to be able to navigate and compile Mono C# in VS. You'll find related emails at http://lists.ximian.com/pipermail/mono-devel-list/2012-May/038908.html and http://lists.ximian.com/pipermail/mono-devel-list/2012-May/038875.html While I originally aimed at developing and debugging with VS (in particular to benefit from mixed-mode debugging) I renounced. I guess this would require a revival of something like Mono tools for VS. I'd like to hear from you if you find an IDE and tools setup that suits you. Cheers From: mono-devel-list-boun...@lists.ximian.com [mono-devel-list-boun...@lists.ximian.com] on behalf of Edward Ned Harvey (mono) [edward.harvey.m...@clevertrove.com] Sent: Saturday, February 15, 2014 1:11 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Getting started on mono sources I'm a developer who uses mono and .NET a lot - and as such, I very often want to read the mono source to see how something is implemented. (Someday, I'll probably stumble across something that should be improved.) Before anything else, I'd like to ask, is there a preferred platform or IDE or something, for working on the mono source? Some getting started on mono development document? Although I've downloaded sources, it's not obvious to me, how to open in for example visual studio, and become a useful human being. (Side note, I ran git clone for several hours today, and eventually decided to just abort it and download zip file.) At the moment, I would love to simply be able to open mcs\class\System\System.Net.Security\SslStream.cs and see how it does the handshake, negotiating protocols and key exchanges, etc. I would *truly* love to launch code examples, and have the ability to step through code, to actually observe its behavior. At present, I'm blindly trying to open things in VS, without a project file or defintions of compiler symbols, and basically all the code is grayed out. While I usually use VS, I'm happy to switch to a different IDE, if for example, Xamarin Studio is the preferred platform to develop on. The goal that I care about is being able to browse, edit, and hopefully even build and debug code, as effectively as possible. Thanks for pointers... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Contributing to xbuild
Hi Marcello, I cannot provide knowledge on xbuld/msbuild as such but can give some background on the .csproj files. I worked on the csproj file generation 1-2 years ago, and introduced the multiple csproj files with the profile as extension. The idea is to aim for solutions that should “just build” as they are under visual studio or monodevelop. Prior to that if my memory serves me right, the “build” process was generating successive versions of the framework libraries, and swapping libraries, and you’d need differing compilation flags and conditional cs file includes in csproj files etc. depending on the profile. Intellisense was going topsy-turvy, too. I reckon that multiple csproj is just plain simpler. I mostly focussed on trying to get a working build process with VS of the System.*.dll libraries for .net 4.5; I could things to build OK though with a few passes. There is an unfortunate wart in the Microsoft compilation toolchain (admittedly would only ever show for one Mono assembly) to work around in profile 2.0. Regarding specifically what you asked: - The availability of Microsoft.Build.Engine.csproj and xbuild.sln _may_ be a legacy (last commit from 2009); (Jonathan Chambers may want to comment on this) - I _think_ that in theory the Microsoft.Build.Engine-net_[2_0,3_5,4_0,4_5]. should reflect the conditional include in the legacy project, and be more up to date regarding the content. - I noticed that MonoDevelop does not support conditional file includes in projects, and there are indeed some in of Microsoft.Build.Engine.csproj Hope this helps; I’d like to contribute more but like you, have limited “spare” time. I’d aim to document things better if anything. Cheers From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Marcelo Zabani Sent: Friday, 20 September 2013 12:01 AM To: Alan Cc: mono-devel Subject: Re: [Mono-dev] Contributing to xbuild Sorry to bring this thread up after so much time, but I haven't had too much time on my hands lately. I've been trying to understand XBuild's and Microsoft.Build.Engine's code in Mono to be able to contribute (even if just a little bit) but I'm having a hard time understanding what is going on. First, I had to do some trickery to get xbuild to build inside Monodevelop. More specifically, I tried opening /mcs/tools/xbuild/xbuild.sln with Monodevelop and build, but before I was able to do that, I had to do the following: Include some files in /mcs/class/Microsoft.Build.Engine/Microsoft.Build.Engine.csproj. The files below were already included in Microsoft.Build.Engine-net_[2_0,3_5,4_0,4_5].csproj: Compile Include=Microsoft.Build.BuildEngine\IBuildTask.cs / Compile Include=Microsoft.Build.BuildEngine\ToolsetCollection.cs / Compile Include=Microsoft.Build.BuildEngine\ToolsetDefinitionLocations.cs / Compile Include=Microsoft.Build.BuildEngine\Toolset.cs / Compile Include=Microsoft.Build.BuildEngine\ProjectLoadSettings.cs / Compile Include=Microsoft.Build.BuildEngine\ExpressionEvaluationException.cs / Compile Include=Microsoft.Build.BuildEngine\LogExtensions.cs / Compile Include=..\Microsoft.Build.Utilities\Mono.XBuild.Utilities\MSBuildUtils.cs / Compile Include=Microsoft.Build.BuildEngine\UnknownToolsVersionException.cs / Compile Include=..\..\tools\xbuild\SolutionParser.cs / * This didn't scare me too much, since I think what actually gets build are the versioned framework files (2_0, 3_5 and so on), but then why have a Microsoft.Build.Engine.csproj? * What I really didn't understand is that I had to change the visibility of UnknownToolsVersionException and some more types from internal to public, since xbuild depends on these (and UnknownToolsVersionException is in the Microsoft.Build.Engine library). This led me to the conclusion that I really don't understand xbuild's build process, since of course when I build Mono it gets built successfully. * When looking at the project files, I coul see some files were included on a per Configuration basis, but MonoDevelop showed them all in the tree view no matter what configuration I chose in the IDE. Is this intended behavior? Sorry for the long email, and thanks in advance. On Thu, Sep 5, 2013 at 12:13 AM, Alan alan.mcgov...@gmail.commailto:alan.mcgov...@gmail.com wrote: Hey, The correct thing to do is probably to build the entire mono class libraries first using the normal procedure for building mono on your OS. Once that's done you should not need to modify assembly references in the csproj files. You may need to add missing cs files to the csproj though. I'm looking forward to your contributions! Alan -- Marcelo Zabani (19) 9341-0221 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Small issues with the Windows msvc builds, and how I got around them
Hi Alex, Thanks for the information; I sometimes need to dive into the C code to get it to compile under MSVC and your heads up is a time saver. You may want to fork+branch and do a pull request if you think these fixes are not temporary hacks. profiler-cov is a .vcxproj file, and AFAIK not generated from makefile as the .csproj files are, as you seem to believe. This nevertheless sounds like a good idea. I’ll work part time on the port of a large C# application to run on Mono+Linux over the coming months; while the target is Linux I think I’ll have the need to build/test on Mono+Windows too and improve the project file generation with MSVS2012. I take due note of your post Regards, J-M From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Alex Forster Sent: Monday, 26 August 2013 3:11 AM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Small issues with the Windows msvc builds, and how I got around them Referring to commit 29c42bf0dc— just a few tips on how I got the -sgen configurations to compile in 32bit release mode with Visual Studio 2012. First issue— msvcrt apparently doesn’t implement _strtoull(). According to this Connect article[1], the functionality exists as _strtoui64(). So, as a comment in the Connect article suggested, in eglib\src\glib.h I added this at around line 275 inside of the _MSC_VER ifdef… #define strtoll _strtoi64 #define strtoull _strtoui64 Second issue— The profiler-cov project links to mono-2.0.lib, but for the -sgen builds, it should be linking to monosgen-2.0.lib. I know the .csproj’s are generated from the makefiles so this isn’t a “real” fix, but all it took for me to get the project to build was to make the project link to the correct library. The x64 build fails miserably because the __asm keyword isn’t supported by Microsoft’s x64 compiler. Alex Forster [1] http://connect.microsoft.com/VisualStudio/feedback/details/758053/missing-strtof-strtold-strtoll-strtoull-functions-from-stdlib-h ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Failing to compile mono on Windows cygwin
A blank line is certainly not the expected behaviour of a Mono 'make'. I tried to checkout the master branch to double check what you describe but encountered instead fatal: Not a git repository for an external module. Seen that git annoyance in the past, can fix but I don't have enough time. I very much doubt the cygwin build is as broken as you describe. I'll forward you in a separate email a PDF of a personal wiki page I have to remind myself how to go about compiling Mono on Windows, in case this helps. You certainly to not need all cygwin packages. From my notes what I typically need to add to a rather Spartan cygwin setup: “autogen.sh requires a few additional packages to be installed in cygwin: bison, libtools, automake of course, and the gettext packages (incl devel packages), or you get a configure: error: msgfmt not found. You need to install the 'gettext' package, or pass --enable-nls=no to autogen.sh or configure” Not sure exactly what you are after with Alternatively, where can I download a zip of the binaries and VS project so that I can start adding tests and fixing bugs?. Which binaries: the mono runtime and/or including the framework (C# assemblies)? Assuming you'd be OK to recompile the mono runtime and the C# assemblies (sounds like you have VS), the core mono runtime (mono-2.0.dll) is relatively easy to build in VS, though sometimes broken and VisualCPP and/or C code needs update/adjustments to get things going. Look under the 'msvc' folder (past outdated instructions). One can definitely set up a mono runtime in debug mode in VS. You can, with a fair bit of work, get the VS project files/solutions: look at msvc/scripts/README. You can even build most of them, though there are quirks. However to my knowledge you cannot debug these through VS, unless something like Mono Tools for Visual Studio is alive and maintained unknown to me. FYI I have a fork intended to better document and improve the VS build use cases, but it is a draft and I struggle to find time for it https://github.com/jmp75/mono/tree/msvc_build_20130604 By the way if someone had advice on a feasible procedure and setup with MonoDevelop for contributors to Mono itself, I for one would be interested. Hope this helps. J-M From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Bryan Crotaz Sent: Sunday, 25 August 2013 9:43 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Failing to compile mono on Windows cygwin I've found a bug in mono, logged it, and created a unit test for it. Now I want to add the test to the Mono test suite, and fix it. So I've now spent 2 days attempting to work out how to get cygwin to work, ending up installing ALL the packages to get autogen to run successfully. I'm now stuck. I run make and get nothing. No error, just a blank line and back to the prompt. I'm assuming this isn't correct. What do I do to fix this? Alternatively, where can I download a zip of the binaries and VS project so that I can start adding tests and fixing bugs? Bryan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Recommended software setup to develop and contribute C# code to Mono
Hi, I have bumped in a bug with time zone date-time conversion (https://r2clr.codeplex.com/workitem/65 but I am pretty sure the underlying issue is e.g. https://bugzilla.xamarin.com/show_bug.cgi?id=1849) I'd like to see whether I can contribute a fix. I am used to test-driven development with VS2012, and would like to emulate this with MonoDevelop/Xamarin Studio on a Debian or Win box. I assume I cannot debug a Mono mscorlib with VS2012 but correct me otherwise. Rather than figure out a set up I'd welcome advice from core Mono contributors: how do you work, what's your software setup? I gave a couple hours trying/googling/doc reading but with limited results. - Got the latest 'master' source from GIT. autogen, make, sudo make install, fine. However an easy option to build and install the debug symbols along is not obvious. - Usually as soon as I compile/install mono from source, even a very recent (Debian unstable) MonoDevelop stops working (see below). Prior attempts to compile MD from source did not work out. $ monodevelop System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall --- System.EntryPointNotFoundException: Mono_Posix_Syscall_get_at_fdcwd Thanks in advance. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] What is the best practice for disposing of transient MonoObject in an embedding scenario
Hi,
I'd like some guidance on how to free memory in an embedded Mono scenario.
I 'monkeyed' a few things started from the embedded samples in the mono
codebase, but they are limited to g_free calls on UTF8 strings. I think I
figured out I needed to use mono_gchandle_new and mono_gchandle_free to 'pin'
(resp. 'free') MonoObject from the embedding application when they re not in
use anymore outside of the CLR. Nevertheless the fate of transient objects is a
bit of a mystery.
Say I have a C# function:
public static object CreateInstance(string typename, object[] ctorArgs)
Which I am calling from C with the code below. What should I do with the
transient MonoArray 'ctor_params' before leaving the function? is mono_free to
call in this case, or would the garbage collector do its job just fine as it is.
{
// snip
MonoArray* ctor_params =
create_array_object(build_method_parameters(ctorParams), Rf_length(ctorParams));
MonoObject * exception, *result;
void** ci_p = (void**)malloc(2*sizeof(void*)); // The array of parameters
for CreateInstance
ci_p[0] = create_mono_string(ns_qualified_typename);
ci_p[1] = ctor_params;
result = mono_runtime_invoke (method, NULL, ci_p, exception);
print_if_exception(exception);
free(ci_p);
// snip
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono from Git with MSVC
Hi Jonathan, I don't think there are some tools to update the VCXproj files. These do not need changing often so a manual process is fine. I still have trouble compiling, in fact with a most recent checkout, I cannot get a compiled mono-2.0.dll in any of the solution's combinations of configuration profiles / platform. Do you have a fork that I can look at to see your fixes? I seem to have stubborn problems with a call to __readfsdword in threads.c. Maybe the presence of Windows Kit 8.0 and its \Include\um\winnt.h is problematic. I am trying to update the readme files as I go, as they are very stale. I will work on my fork https://github.com/jmp75/mono (GitHub not letting me push yet as I write and confusing me, so it may be 5 mth old when you look.). If you already working on it not need to double up however. Regards. From: Jonathan Lima [mailto:greenbo...@gmail.com] Sent: Tuesday, 14 May 2013 8:27 AM To: Perraud, Jean-Michel (CLW, Black Mountain) Cc: r...@xamarin.com; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Building Mono from Git with MSVC I probably don't have them anymore as I fixed the build errors. There are any tools to update the MSVC projects automatically? I will prepare a pull request with the fixed projects. Also SGen build crashes with corrupted stack, probably missing pointer math magic from GCC(saw something like that on mono doc about msvc). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono from Git with MSVC
It seems I was barking up the wrong tree. A week ago the following variable
assignments were added to the threads.c, coming from the NaCl contributions it
seems. For some reason, the MSVC++ compiler is not happy. Commenting out and
then libmonoruntime.vcxproj compiles.
Any suggestions? I strongly suppose just deleting is a bad idea.
*staddr = NULL;
*stsize = 0;
Added at the beginning of:
mono_thread_get_stack_bounds (guint8 **staddr, size_t *stsize)
{
Cheers
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of
jean-michel.perr...@csiro.au
Sent: Tuesday, 4 June 2013 5:05 PM
To: greenbo...@gmail.com
Cc: mono-devel-list@lists.ximian.com
Subject: [ExternalEmail] Re: [Mono-dev] Building Mono from Git with MSVC
Hi Jonathan,
I don't think there are some tools to update the VCXproj files. These do not
need changing often so a manual process is fine.
I still have trouble compiling, in fact with a most recent checkout, I cannot
get a compiled mono-2.0.dll in any of the solution's combinations of
configuration profiles / platform. Do you have a fork that I can look at to see
your fixes?
I seem to have stubborn problems with a call to __readfsdword in threads.c.
Maybe the presence of Windows Kit 8.0 and its \Include\um\winnt.h is
problematic.
I am trying to update the readme files as I go, as they are very stale. I will
work on my fork https://github.com/jmp75/mono (GitHub not letting me push yet
as I write and confusing me, so it may be 5 mth old when you look.). If you
already working on it not need to double up however.
Regards.
From: Jonathan Lima [mailto:greenbo...@gmail.com]
Sent: Tuesday, 14 May 2013 8:27 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: r...@xamarin.commailto:r...@xamarin.com;
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Building Mono from Git with MSVC
I probably don't have them anymore as I fixed the build errors.
There are any tools to update the MSVC projects automatically? I will prepare a
pull request with the fixed projects.
Also SGen build crashes with corrupted stack, probably missing pointer math
magic from GCC(saw something like that on mono doc about msvc).
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 3.0.6 Windows installer - missing dcms.bat, and why only 32bits
Hi, While trying to use xbuild on Windows I noticed that dmcs.bat seems to be missing from the 3.0.6 /bin directory Microsoft.CSharp.targets: error : Error executing tool 'C:\PROGRA~1\MONO-3~1.6\bin\dmcs.bat' [...] Native error= The system cannot find the file specified. I think it is present in the latest 2.10.x stable installer. Not difficult to work around of course, but I don't think this was mentioned on mailing lists yet. Second question on the Windows installer: is there an intent to distribute 64 bits out of the box in the near future? I am working on a package that should ideally run embedded Mono from 32 or 64 bit processes (namely the R statistical software). While I know this is doable, a Mono installer that sets up both architectures on Windows would make it simpler to automate a build against 32 and 64 bits of mono-2.0.dll. Is there interest/plan from the maintainers of the Windows installer to upgrade to support both architecture? I am mindful that this is probably no small amount of work to set up. Regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 3.0.6 Windows installer - missing dcms.bat, and why only 32bits
Hi, While trying to use xbuild on Windows I noticed that dmcs.bat seems to be missing from the 3.0.6 /bin directory Microsoft.CSharp.targets: error : Error executing tool 'C:\PROGRA~1\MONO-3~1.6\bin\dmcs.bat' [...] Native error= The system cannot find the file specified. I think it is present in the latest 2.10.x stable installer. Not difficult to work around of course, but I don't think this was mentioned on mailing lists yet. Second question on the Windows installer: is there an intent to distribute 64 bits out of the box in the near future? I am working on a package that should ideally run embedded Mono from 32 or 64 bit processes (namely the R statistical software). While I know this is doable, a Mono installer that sets up both architectures on Windows would make it simpler to automate a build against 32 and 64 bits of mono-2.0.dll. Is there interest/plan from the maintainers of the Windows installer to upgrade to support both architecture? I am mindful that this is probably no small amount of work to set up. Regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Embedded mono; getting in C a pointer from an IntPtr object
Hi,
I have a scenario where some C function is getting a MonoObject (*pobj) that
happens to be an IntPtr. As the native pointer is known to be of a certain
native type (SEXP), how do I retrieve it? I tried a few things, the latest
being:
type_il =
mono_type_get_type(mono_class_get_type(mono_object_get_class(pobj)));
switch(type_il) /*MonoTypeEnum*/
{
case MONO_TYPE_I: // IntPtr, that we assume to be a
SEXP as coming from R.NET. result =
(SEXP)(void*)mono_object_unbox(rclr_mono_call_inst_method(ToPointer, pobj,
NULL, 0));
break;
I soon get an access violation not long after the function return.
I have a working solution when hosting the Microsoft CLR but this is not
directly transferable to Mono given the significantly different APIs.
Regards
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] issue during compile libmono in visual studio c++ 2010
Hi, The compilation instructions (on the web site and in the msvc README) are a bit outdated, but this is relatively easy to figure out. I can compile libmono and its dependencies with minimal changes to a recent git clone. I used VS2012 but I don't think VS2010 would be a very different story. I may try to give it a try with VSC++ express 2010 later on and will let you know. The only notable thing I needed to modify is to remove a small '#ifdef MONOTOUCH' conditional compilation in /mono/mini/aot-runtime.c. It looked perfectly correct, and certainly is for the cygwin based build, but tripped the VS VC++ tools. You should not need a 'semaphore.h' on a windows platform; so far as I can see its inclusion is conditioned on '#if defined(HAVE_SEMAPHORE_H) !defined(HOST_WIN32)', and that is evaluated to false. Hope this helps. Regards From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of ? Sent: Friday, 25 January 2013 5:10 PM To: mono-devel-list Subject: [Mono-dev] issue during compile libmono in visual studio c++ 2010 dear: I want to compile libmono in vs2010. I follow the instuction on http://www.mono-project.com/Compiling_Mono_VSNET,and I know I only need to build eglib,libgc ,genmdesc and libmono. I faced the issue that semaphore.h can't be found, and I search and find there is semaphore.h in C:\cygwin\usr\include, and I include it then complie, the result is that causes more errors(most of that are about grammar). Can you help me to solve that? mono is very importance to me,(and I are using it to all my project , including android,ios) thank you very much! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Upcoming pull request; Generating csproj files and compiling Mono in Visual Studio
Hi, I finally followed up on some upgrades to the build process generating the visual studio csproj and solution files. For reference prior discussions are at http://lists.ximian.com/pipermail/mono-devel-list/2012-May/thread.html#38852. I have a fork at https://github.com/jmp75/mono/commits/master. Before submitting my first pull request I'd like to double-check where the bar is. Mostly, I do not know who uses these .csproj files and for what; if you do, I'd like to hear advice/comment from you. Current status is: - Generates distinct project files for successive versions of assemblies whose build is iterative (circular dependencies) - Projects reference other projects, in preference to referencing relative paths to a DLL. - Most assemblies then compile in visual studio, BUT there are some issues yet to weed out (mcs-build, some unit test assemblies) - Multiple solutions files are generated, with different scopes (the full one has ~300 projects) - Tested on a Windows+cygwin+Mono+MS.NET setup. Not yet run on Linux. I'll polish what I can, meaning documentation and hopefully figure out some compilation issues, but don't want to raise the bar and delay the pull request unnecessarily. Regards, J-M ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Seeking advice on converting basic value types from the CLR representation to native C types, using mono embedding
Hi,
I am working on a package to access the Mono (resp. MS.NET) CLR from the R
statistical language. I am trying to convert 'simple' CLR value types (e.g.
string, double, bool, DateTime) to marshall them to their R equivalent. I
managed to deal with the 'bool', but stumbled on the DateTime
I think Mono's print_field_value in debug-helpers.c seems the closest I can
infer from, to mimic it. But I have trouble doing so. I understand little of
what I get returned from mono_object_unbox. Any guidance on how to go about it
is welcome. In return, I'd like to contribute some 'howto' documentation to
Mono.
The task is logged at http://r2clr.codeplex.com/workitem/14 for background info.
You can get the complete source code from http://r2clr.codeplex.com if you
wish, but I include below code that should convey the idea.
Regards,
J-M
//snip
type_il = mono_type_get_type(mono_class_get_type(mono_object_get_class(pobj)));
switch(type_il) /*MonoTypeEnum*/ {
case MONO_TYPE_R8 :
result = mkNumericSexp(1, (double*)mono_object_unbox(pobj));
break;
case MONO_TYPE_STRING :
str = mono_string_to_utf8((MonoString*)pobj); // this one should work;
yet to pass formal unit test.
result = mkCharSexp(1, str);
mono_free(str);
break;
case MONO_TYPE_BOOLEAN: // this one seems to work
result = mkBoolSexp(1, (int*)mono_object_unbox (pobj));
break;
case MONO_TYPE_VALUETYPE:
{
if(strcmp( klassName, DateTime) == 0)
{
double * valSinceNinteenhunds = getRDateOffset(pobj); // this
seems very off.
result = mkDateSexp(1, valSinceNinteenhunds);
break;
}
}
//snip
double * getRDateOffset(CLR_OBJ * pobj) {
MonoMethod * method = rclr_mono_get_method( spTypeClrFacade,
GetRDateDoubleRepresentation, 1); // C# GetRDateDoubleRepresentation returns
a double, a TimeSpan.TotalDays
void ** params = (void**) (pobj);
MonoObject * exception;
// FIXME: seems I should seek gint64; Where is it defined in the mono
distribution include headers? seems absent from glib.h and anywhere else.
return (double*)mono_object_unbox(mono_runtime_invoke(method, NULL,
params, exception)); }
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
Hi Marek, I have ironed out most issues I had to get to compiling a large part of the assemblies in VS/msbuild from scratch. What was the scope of the cleanup you are undertaking? I'd like to put in a pull request, but would like to have an idea of the scope of your change to minimise duplicates/differences. I use mostly SVN so the procedure to put in a pull request will be a learning experience. I've added a few modifications to a couple of makefiles, but by and large the bulk is in the genproj.cs file. The key changes were: - The msbuild compilation targets (for v4.0) always adds a reference to System.Core behind one's back. I've found a way to turn this off using the csproj template. - Cyclic dependencies are flattened out and avoid reusing identical build output paths, to improve clarity and robustness. Regards, J-M From: Marek Safar [mailto:marek.sa...@gmail.com] Sent: Saturday, 19 May 2012 6:41 PM To: Perraud, Jean-Michel (CLW, Black Mountain) Cc: michael.mu...@welchallyn.com; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files Hi, Thanks Miguel, your description helped me figure out a couple of key things. I'm gradually getting on top of the mcs/class build process and its translation to VS solutions/projects. There was already a lot of prior work done by Sebastien Pouliot (I think) a few years ago. That's not correct, all projects were regenerated recently. About the corlib-build issue, you don't need to build any of *-build.csproj projects, they are needed only on systems with no .NET 4 API. I have done some work on cleaning this up recently but it's not yet finished. Marek One thing I came across is that the project for corlib-build builds if targeting .Net 2.0, but fails on .NET 4.0 with a few errors such as follows. The only related issue I found (https://github.com/nikhilk/scriptsharp/issues/156) suggests that .NET4.5 may be the issue. Any advice on handling this is welcome. I need to add project dependencies on a couple of outputs from the basic profile to overcome the issue and still target 4.0. However I do not like the departure from the cygwin build process. The type 'System.Diagnostics.TextWriterTraceListener' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. C:\src\mono\mono\mcs\class\corlib\System.Diagnostics\ConditionalAttribute.cs 35 11 corlib-build The type 'System.Collections.Generic.ISet`1T0' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. C:\src\mono\mono\mcs\class\corlib\System.Collections.Generic\CollectionDebuggerView.cs 32 11corlib-build Cheers, J-M ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
Hi Miguel, mono-devel subscribers,
Thanks Miguel, your description helped me figure out a couple of key things.
I'm gradually getting on top of the mcs/class build process and its
translation to VS solutions/projects. There was already a lot of prior work
done by Sebastien Pouliot (I think) a few years ago.
One thing I came across is that the project for corlib-build builds if
targeting .Net 2.0, but fails on .NET 4.0 with a few errors such as follows.
The only related issue I found
(https://github.com/nikhilk/scriptsharp/issues/156) suggests that .NET4.5 may
be the issue. Any advice on handling this is welcome. I need to add project
dependencies on a couple of outputs from the basic profile to overcome the
issue and still target 4.0. However I do not like the departure from the cygwin
build process.
The type 'System.Diagnostics.TextWriterTraceListener' is defined in an assembly
that is not referenced. You must add a reference to assembly 'System,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
C:\src\mono\mono\mcs\class\corlib\System.Diagnostics\ConditionalAttribute.cs
35 11 corlib-build
The type 'System.Collections.Generic.ISet`1T0' is defined in an assembly that
is not referenced. You must add a reference to assembly 'System,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
C:\src\mono\mono\mcs\class\corlib\System.Collections.Generic\CollectionDebuggerView.cs
32 11corlib-build
Cheers,
J-M
From: Miguel Mudge [mailto:michael.mu...@welchallyn.com]
Sent: Saturday, 12 May 2012 12:34 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
Making progress with msvc, with a lot of second guessing, but I cannot seem to
fully get out of the circular dependencies easily. After fixing a few things,
there seems to be a two to three stage build process ('basic', 'build' and,
well, the huge rest). I can build the 'basic' stuff with references being the
MS.NEThttp://MS.NET libraries it defaults to, but the 'build' phase fails
both with dependencies on the basic system or the MS.NEThttp://MS.NET
libraries (missing implementations or ambiguous references). Well done for you
to sort it all out.
Our build uses *none* of the MS.NEThttp://MS.NET libraries - every project
*only* depends on other projects in the same Mono solution file. All of the
projects reference the mscorlib project built in that solution, *never*
Microsoft's mscorlib.dll (see Project Properties - Build - Advanced - Do
not reference mscorlib.dll).
mscorlib has these compilation symbols: INSIDE_CORLIB LIBC NET_1_1 NET_2_0
NET_3_0 NET_3_5 NET_4_0
And it has a few links to external files: Aes.cs, Consts.cs, Locale.cs,
MonoTODOAttribute.cs, SemaphoreFullException, TimeZoneInfo.AdjustmentRule.cs,
TimeZoneInfo.Android.cs, TimeZoneInfo.cs, TimeZoneInfo.TransitionTime.cs.
We were able to determine most of those files by looking at corlib.dll.sources
- definitely look at the .sources files for the other DLLs too... although it's
better to look at the Linux build in-action.
You should be able to build mscorlib with the above info. Here is the info for
system (notice the dash, as in minus):
System -XML -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0
CONFIGURATION_2_0
Depends on: mscorlib project
System.Xml then depends on the above.
System -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0
XML_DEP
Depends on: mscorlib project, System.Xml project
Mono.Security then depends on mscorlib and System -Config
Mono.Configuration then depends on mscorlib, System.Xml and System -Config
System: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0
CONFIGURATION_DEP XML_DEP SECURITY_DEP
Depends on: mscorlib, System.Xml, System.Configuration, Mono.Security
Don't trust the above though - I think there's a missing step, there may need
to be 4 builds of System (one before XML_DEP is added, one before SECURITY_DEP
is added, one before CONFIGURATION_DEP is added, then the final build with all
3 constants added).
The best thing to do is compile mcs in Linux and gather this information:
- The order in which each library is built - including if it is built multiple
times.
- What dependencies each build has.
- What compile-time constants are set.
- What files are a part of the build.
I would definitely add you to my list of super-cool people if you duplicated /
modified the Linux build process to capture the above 4 things to generate a
working MSVC solution - it's just XML files, an xslt might do this well. I'm
sure the Mono folks would be happy to include the output of such a process in
each source release to make it easier on us MSVC-centric folks.
- Kipp
It sounds like your approach is similar to that in the 'msvc' folder and
related
Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
Thank you for this info Miguel
Making progress with msvc, with a lot of second guessing, but I cannot seem to
fully get out of the circular dependencies easily. After fixing a few things,
there seems to be a two to three stage build process ('basic', 'build' and,
well, the huge rest). I can build the 'basic' stuff with references being the
MS.NET libraries it defaults to, but the 'build' phase fails both with
dependencies on the basic system or the MS.NET libraries (missing
implementations or ambiguous references). Well done for you to sort it all out.
It sounds like your approach is similar to that in the 'msvc' folder and
related makefile targets, but I probably miss many details. I found that I
could run the make targets generating csproj files only after a successful
'make' on cygwin, using anciliary files (.response) from the call to 'make'. I
wonder how similar to what you describe this is. My question may be naive, but
what do you mean by compiler constants, build order and files used? Are you
post-processing the captured output redirected to a file?
I never really had to do much with makefiles, and with a codebase the size of
Mono, this is a steep learning curve.
Cheers,
J-M
From: Miguel Mudge [mailto:michael.mu...@welchallyn.com]
Sent: Tuesday, 8 May 2012 12:30 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files
We've been building the 2.10.2 Mono framework libraries in Visual Studio. We
performed a build on Linux, copied the compiler constants, build order and
files used, and use this information to create the Visual Studio project - we
did not start from Mono's msvc. It was a very manual process, but I am pleased
with the output.
We don't compile all of the libraries since our embedded device doesn't have
the space. Most of the difficulty is in the roots anyways - for example, we
have several System.dll projects, which are incrementally more dependent, in
order to solve circular dependency problems. Picture attached:
It seems like the only way to reliably copy the build process into MSVC is to
actually run the mcs make. You might be able to hack it a bit to mock a build,
grab the compile flags/files and then generate msvc files from that.
Thanks,
Michael Kipp Mudge | Welch Allyn | Lead Software Engineer
315-554-4057 | michael.mu...@welchallyn.commailto:michael.mu...@welchallyn.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compiling Mono with Visual Studio and .pdb files
Hi, I gather that some effort was made to compile Mono with VS or the .NET framework SDK on Windows a few years ago. This past couple of days I looked into it as I am developing for Mono and MS .NET embedding. While I use occasionally MonoDevelop, which may be the preferred tool now, with debug much better than a few years ago, I'd like to stick to one IDE (even the grey-on-grey thing known as VS2011 beta) on Windows. There has not been a lot of activity lately under the msvc folder. The build process is a bit of a rocky road, understandably, and I logged my tribulations for myself. I want to gauge the interest in dusting off the build process. I noticed that Marek Saraf (Novell?) has commited this past month. Advice/ideas on the overall build process desirable is welcome. I cannot commit to set it up (time and know-how pending), but discussions cannot hurt. Cheers, J-M ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
