Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
Michael Franz, please check if your custom built version of the mono binary is in the path during the rest of the build, or that code Michael Hutchinson pointed out will fail... Hope it helps, Rafael Teixeira O..:.) On Mon, Feb 17, 2014 at 2:50 AM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz mvfr...@gmail.com wrote: On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.com wrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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 -- Michael Hutchinson http://mjhutchinson.com ___ 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] Recent xbuild fixes causing issues with finding mcs
TBH this seems like a runtime bug, it should not rely on itself being in PATH. On 17 February 2014 09:34, Michael Franz mvfr...@gmail.com wrote: On Mon, Feb 17, 2014 at 7:38 AM, Rafael Teixeira mono...@gmail.com wrote: Michael Franz, please check if your custom built version of the mono binary is in the path during the rest of the build, or that code Michael Hutchinson pointed out will fail... Adding the bin directory of my Mono installation to the PATH does solve the problem. I can work with this, it is just a change in the usage. Hope it helps, Rafael Teixeira O..:.) On Mon, Feb 17, 2014 at 2:50 AM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz mvfr...@gmail.com wrote: On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.com wrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On Mon, Feb 17, 2014 at 12:22 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: TBH this seems like a runtime bug, it should not rely on itself being in PATH. Should I file a bug against the runtime? What is the best way to describe this issue? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
Yes, but xbuild uses Process.Start, which automatically executes exe files using Mono. Not sure why that's failing on your machine. On 15 February 2014 22:13, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 10:02 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: AFAIK something's wrong with the installation if $prefix/lib/mono/4.5/mcs.exe is missing. What does your $prefix/bin/mcs point to? It points to a binary that does not run on its own. bash-4.1$ ./lib/mono/4.5/mcs.exe --version bash: ./lib/mono/4.5/mcs.exe: cannot execute binary file but, if I run it with mono it will work. bash-4.1$ bin/mono ./lib/mono/4.5/mcs.exe --version Mono C# compiler version 3.2.7.0 Prior to the change, it was the mcs wrapper that was being executed, after the change, it is trying to run the .NET binary directly. The contents of mcs is: #!/bin/sh exec /opt/local/JenkinsBuilds/bin/mono $MONO_OPTIONS /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe $@ On 15 February 2014 10:51, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool /opt/local/JenkinsBuilds/bin/mcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments:
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.comwrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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] Recent xbuild fixes causing issues with finding mcs
No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz mvfr...@gmail.com wrote: On Sun, Feb 16, 2014 at 7:34 AM, Andrés G. Aragoneses kno...@gmail.com wrote: On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. ___ 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 -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Recent xbuild fixes causing issues with finding mcs
Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool */opt/local/JenkinsBuilds/bin/mcs* execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Math.cs Utilities/Measurements/PerformanceStatistics.cs obj/Debug/.NETFramework,Version=v4.5.AssemblyAttribute.cs /target:library /define:DEBUG;TRACE /nostdlib /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll /warn:4 /opt/local/JenkinsBuilds/lib/mono/4.5/Microsoft.CSharp.targets: error : Error executing tool '/opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe': I checked the commit logs, and it looks like there are commits that would affect this behavior. Now, it might be that I was doing something wrong from the start and now I need to fix the process, but it seems like a simple process. e753ca2 Michael Hutchinson [xbuild] Fix dependency in C# targets c197478 Michael Hutchinson [xbuild] Fix 2.0 tests to handle mcs sdk argument 693176c Michael Hutchinson [xbuild] Fix Tooltask.ToolPath behaviour to match .NET df52831 Michael Hutchinson [xbuild] Make ToolLocationHelper work better for 2.0/3.5 a55c588 Michael Hutchinson [xbuild] Fix typo that broke 2.0/3.5 targets
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool */opt/local/JenkinsBuilds/bin/mcs* execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Math.cs Utilities/Measurements/PerformanceStatistics.cs obj/Debug/.NETFramework,Version=v4.5.AssemblyAttribute.cs /target:library /define:DEBUG;TRACE /nostdlib /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll /warn:4 /opt/local/JenkinsBuilds/lib/mono/4.5/Microsoft.CSharp.targets: error : Error executing tool '/opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe': I checked the commit logs, and it looks like there are commits that would affect this behavior. Now, it might be that I was doing something wrong from the start and now I need to fix the process, but it seems like a simple process. e753ca2 Michael Hutchinson [xbuild] Fix dependency in C# targets c197478 Michael Hutchinson [xbuild] Fix 2.0 tests to handle mcs sdk argument 693176c Michael Hutchinson [xbuild] Fix Tooltask.ToolPath behaviour to match .NET df52831 Michael Hutchinson
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
AFAIK something's wrong with the installation if $prefix/lib/mono/4.5/mcs.exe is missing. What does your $prefix/bin/mcs point to? On 15 February 2014 10:51, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool /opt/local/JenkinsBuilds/bin/mcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Math.cs Utilities/Measurements/PerformanceStatistics.cs obj/Debug/.NETFramework,Version=v4.5.AssemblyAttribute.cs /target:library /define:DEBUG;TRACE /nostdlib /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll /warn:4 /opt/local/JenkinsBuilds/lib/mono/4.5/Microsoft.CSharp.targets: error : Error executing tool '/opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe': I checked the commit logs, and it looks like there are commits that would affect this behavior. Now, it might be that I was doing something wrong from the start and now I need to fix the process, but it seems like a simple process. e753ca2 Michael Hutchinson [xbuild] Fix dependency in C# targets c197478 Michael Hutchinson
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On Sat, Feb 15, 2014 at 10:02 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: AFAIK something's wrong with the installation if $prefix/lib/mono/4.5/mcs.exe is missing. What does your $prefix/bin/mcs point to? It points to a binary that does not run on its own. bash-4.1$ ./lib/mono/4.5/mcs.exe --version bash: ./lib/mono/4.5/mcs.exe: cannot execute binary file but, if I run it with mono it will work. bash-4.1$ bin/mono ./lib/mono/4.5/mcs.exe --version Mono C# compiler version 3.2.7.0 Prior to the change, it was the mcs wrapper that was being executed, after the change, it is trying to run the .NET binary directly. The contents of mcs is: #!/bin/sh exec /opt/local/JenkinsBuilds/bin/mono $MONO_OPTIONS /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe $@ On 15 February 2014 10:51, Michael Franz mvfr...@gmail.com wrote: On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz mvfr...@gmail.com wrote: Hi, I see there have been a few changes to xbuild since February 10th, 2014. February 10th is the last time I was able to build my local C# project using mono head. This is a simple project that I have just started and am planing to build on both mono and .NET. The issue seems to be that xbuild has changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs - /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. My locally build mono install is in /opt/local/JenkinsBuilds and my builds are all run via Jenkins. The build process is: - use premake5 to generate Visual Studio 2012 project files (note I am using .net 4.5 specific features) - use xbuild to build - use mono version of nunit to test The working build out put was like this: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/10/2014 9:56:00 PM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target GenerateTargetFrameworkMonikerAttribute: Skipping target GenerateTargetFrameworkMonikerAttribute because its outputs are up-to-date. Target CoreCompile: Tool /opt/local/JenkinsBuilds/bin/mcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Measurements/PerformanceStatistics.cs /target:library /define:DEBUG;TRACE /platform:AnyCPU /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll /warn:4 The broken build is now producing: + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln XBuild Engine Version 12.0 Mono, Version 3.2.7.0 Copyright (C) 2005-2013 Various Mono authors Build started 2/15/2014 8:50:52 AM. __ Project /var/lib/jenkins/jobs/CI/workspace/QTS.sln (default target(s)): Target ValidateSolutionConfiguration: Building solution configuration Debug|Any CPU. Target Build: Project /var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj (default target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory bin/Debug/ Created directory obj/Debug/ Target CopyFilesMarkedCopyLocal: Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' Copying file from '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll.mdb' Target GenerateSatelliteAssemblies: No input files were specified for target GenerateSatelliteAssemblies, skipping. Target CoreCompile: Tool /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/Debug/QTS.dll Properties/AssemblyInfo.cs Utilities/Math.cs Utilities/Measurements/PerformanceStatistics.cs obj/Debug/.NETFramework,Version=v4.5.AssemblyAttribute.cs
