| Age | Commit message (Collapse) | Author |
|---|
|
* Initial commit to migrate libgc to bdwgc.
* Fix submodule url
* Don't force Boehm as runtime wrapper. Was just for testing locally.
* Build bdwgc as single object file. Helps with performance.
* Bump bdwgc submodule.
* Attempt to fix windows MSVC based build.
* Remove any references to GC_INSIDE_DLL as we manually managed threads on Windows.
* Allow building boehm on Windows amd64.
* Allow building boehm with msvc.
* Bump bdwgc to fix line endings
* Use LF for sh, am, m4, and ac files in bdwgc
* Bump bdwgc & libatomic_ops with fix for cygwin
* Bump bdwgc to fix mono-boehm being generated as libtool wrapper script.
* Link the static boehm library.
* Revert "Link the static boehm library."
This reverts commit 1f90d81d08308a61c890743cd79d8f6bb791bc99.
* Use --export-all-symbols on cygwin/mingw to fix issues with boehm causing mono symbols not to be exported.
* Fix
|
|
|
|
|
|
* Enable MSVC builds of Mono w/ ENABLE_NETCORE
* Fix non-netcore build
* Move the ENABLE_NETCORE definition to config.h where it belongs
* Replace .def with linker #pragmas
* TARGET_WIN32 -> HOST_WIN32 && HOST_X86
* Pick up MONO_ENABLE_NETCORE from cygconfig.h
* Make `./configure --with-core=only` MSVC builds working
* Include netcore sources unconditionally, move the condition into the .c file
* Fix MSVC C++ netcore build on Win32
|
|
(#11946)
* Add support for LLVM asserts in internal LLVM build on Windows.
* Only build LLVM using MSVC if not cross compiling.
If not cross compiling, building runtime where host/target is Windows, only
build and use LLVM as part of msvc build (only supported configuration),
disabled on gcc build.
Enforce 64-bit LLVM support when building using Visual Studio solution file.
* Disable Windows LLVM Visual Studio build on unsupported configurations.
Automatically disable Windows LLVM build in Visual Studio. This enables
the option to configure using --enable-llvm but still build all runtime
configurations from within Visual Studio. A warning will be issued into
build logs when LLVM support is disabled for a specific build configuration.
* Fix so build-init always have cygconf.h available when needed.
|
|
|
|
build. LLVM build follows similar pattern as BTLS build and will be build
as part of regular Visual Studio build Mono runtime if LLVM has been enabled
through the autogen.sh, --enable-llvm or –with-llvm argument. It is also
supports msbuild properties MONO_ENABLE_LLVM, MONO_EXTERNAL_LLVM_CONFIG,
if Visual Studio Mono runtime has been built without using autogen.sh.
When just using –enable-llvm, LLVM build will try to build internal LLVM
branch under external/llvm or if override has been set in props file
(using MONO_INTERNAL_LLVM_SOURCE_DIR), an alternative LLVM source
directory path. If –with-llvm has been used pointing to an llvm-config.exe,
no internal LLVM will be build, but the external LLVM build will be used.
Needed LLVM executables (opt.exe, llc.exe) will be installed into regular
Visual Studio Mono runtime build output directory.
The internal Mono LLVM 6.0 release will build as part of changes to this
commit, but it has not yet been fixed to work as expected during runtime.
That work will be done in different commit. The Mono LLVM 3.6 branch will
however work as expected for Windows x64 and can be setup and used using
–with-llvm argument or build as part of Visual Studio build Mono runtime
by enabling msbuild properties, MONO_ENABLE_LLVM and
MONO_INTERNAL_LLVM_SOURCE_DIR.
|
|
|
|
By default, all projects are build using "default" compiler based on source
file extension. There is a property in mono.props, MONO_COMPILE_AS_CPP
that could change this and build selected projects (eglib, libgcmonosgen,
libmini, libmono-dynamic, libmono-static, libmonodac, libmonoruntime,
libmonoutils, mono, monodis, monograph and pedump) using C++ compiler.
MONO_COMPILE_AS_CPP property could be set when calling msbuild
or through VS property manager IDE. Default value is false building using
"default" compiler (current behavior). When setting MONO_COMPILE_AS_CPP=true
the build prefix will be altered to make sure the C++ build gets its own build
folder, parallel to default build folders.
Example of building using C++ compiler from msbuild:
msbuild /p:PlatformToolset=v140 /p:Platform=x64 /p:Configuration=Release /p:MONO_TARGET_GC=sgen /p:MONO_COMPILE_AS_CPP=true msvc/mono.sln
|
|
|
|
* Modernize Windows random number generation.
- Less code.
- Less chance for failure.
- Not seedable.
- Requires Windows 7 or newer -- er, require Vista or newer until/unless Unity drops it, under ifdef.
This might get much further pruned with CoreFX import, which is on hold here, and doesn't really change much, except to indeed drop Vista support. (https://github.com/mono/mono/pull/9249)
|
|
Uses mono LLVM master branch, build using cmake and VisualStudio 2015/2017.
Commit adds support for AOT/Full AOT LLVM codegen for Windows x64 Visual Studio
build mono runtime. Normal configure/make using cygwin won’t support LLVM and will
trigger an error if configured.
In order to build using LLVM first mono LLVM master branch must be build using
static linked LLVM configuration (dynamic loading can be added later),
NOTE mono LLVM build needs to include the following commit,
https://github.com/mono/llvm/commit/9b92b4b87607e137266f84dc307181b8842fe54a
in order to successfully build on Windows x64.
Build mono LLVM branch using the following cmake configuration:
-DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ZLIB=OFF
-DLLVM_TARGETS_TO_BUILD="X86"
-DCMAKE_CROSSCOMPILING=False
-DCMAKE_SYSTEM_NAME=Windows
Use cmake with -G "Visual Studio 14 2015 Win64" to generate VS 2015 x64
targets. NOTE, if mono runtime is build using VS 2017, then LLVM should
be build using the same VS version using -G "Visual Studio 15 2017 Win64"
To enable LLVM build in mono.sln, set MONO_ENABLE_LLVM to “true” and make
sure MONO_LLVM_INSTALL_DIR_PREFIX points to the install directory used in
LLVM build above, default msvc/dist/llvm. Above LLVM properties can also
be set if build using msbuild.
A sample LLVM configure script has been included in msvc/llvm-cmake-config.bat.
|
|
|
|
mono_atomic_<op>_<type>, with a consistent signature on all platforms, including Windows implementation. (#5767)
* [runtime] Rename atomic functions from the win32 style naming to mono_atomic_<op>_<type>, with a consistent signature on all platforms. This fixes a large number of warnings on windows.
* Add Windows implementaiton of mono_atomic_*.
* Windows implementation of mono_atomic_* inline functions.
* Changed naming typo in mono_atomic_xchg_i32Add and mono_atomic_xchg_i32Add64.
* Fixed some additional signed/unsigned/volatile warnings when using mono_atomic_*
* Fixed some smaller additionl warnings.
* Fix Interlocked* to mono_atomic_* name change in signal.c
* Additional name adjustment of atomics.
Aligning more towards C11/C++11 standard namings:
mono_atomic_xchg_add_i32|i64 -> mono_atomic_fetch_add_i32|i64
Changed from mono_atomic_add to mono_atomic_fetch_add in cases when return
type is not used.
Also includes small mingw build fix on Windows.
* Aligned loads with C++11 implementation using explicit compiler barrier.
On x86/x64 Windows, reading a properly aligned 8,16,32 bit volatile variable
(using /volatile:ms extension) should have acquire semantics. On x64
this also includes 64-bit properly aligned volatile variables.
The C++11 implementation does however include an explicit _ReadWriteBarrier in
its sequentially consistent implementation to instruct compiler to not reorder
load/stores. Since compiler supports two modes of volatile behavior (ms/iso)
this additional barrier is probably there for consistency, independent of the
behavior of volatile keyword.
NOTE, the x86/x64 CPU architecture has strong guarantees regarding load/store of
memory operations, so issuing a CPU memory barrier for loads should not be needed
(and is not done in C++11 atomics implementation).
This commit also adds a couple of optimizations for 32-bit loads and for x64,
64-bits loads. The C++11 implementation uses the same pattern loading them as 8
and 16 bits variables, so no need for Interlocked* calls to load 32-bit and for x64
64-bit variables.
|
|
|
|
library support.
|
|
Make libmono-static lib file include all needed runtime libs making it easier to
link and distribute as part of Mono SDK.
Commit also updates linking of vcxprojs in mono.sln to use merged static lib.
|
|
similar to utils/ etc. (#5297)
|
|
This change extracts the eglib source files from the build instuctions
for builds via MSVC on Windows. It also separates the source files into
platform-specific and common .targets files. This provides more
flexibility for builds from MSVC in a few important ways:
1. We can do MSVC-based builds for platforms that will not be pushed to
public repos by checking out the Mono code externally and importing the
.targets files into a custom .vcxproj for the platform.
2. We can replace the platform specific .targets files with a custom set
of source files to implement a different platform abstraction layer
that will not be public without the need to merge changes to the
.vcxproj from the public repo.
This allows for ease of synchronizing changes to the public Mono
repo with private forks, while _not_ changing the behavior of the code
in the public repo.
|
|
additional test/debug projects. (#3420)
* Fixing linker warning when building libmono DLL.
After splitting mono runtime into a static library used when building libmono
DLL, we got a linker warning since there were no object files left in the
libmono project. There was also a sematic issue with the current organization
of DllMain since it is located in driver.c that will be compiled into the static
library and then consumed by the linker building the DLL. In cases where the
static library was consumed directly it would still include DllMain entry point.
By splitting the DllMain method implementation into a separate specific windows file
we can both resolve the linker warning and remove the DllMain method implementation from the static
library and only include it when building the libmono DLL.
* Visual Studio projects support to optimally link mono applications using static libmono library.
Added a new property, MONO_USE_STATIC_LIBMONO that can be used to link some
mono applications, for example mono(-sgen).exe, towards static version of libmono.
This gives us the option to build a binary without dependencies on other runtime binaries
minimizing what’s needs to be deployed in order to run mono. This in combination with static linked c-runtime
(another option available through a VS property) will produce a mono runtime binary without
addition dependencies except .NET assemblies deployed by mono runtime users.
The default is still using the dynamic version of libmono as before.
* Visual Studio project to test/debug testdriver tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run testdriver related tests
directly from within Visual Studio.
Commit also includes an additional configuration script that can be used test projects in order
to setup a mono config file. The testdriver project uses this to create a unique configuration
files pointing to the build libtest.dll for running configuration. The configuration file will then
be used when the tests are executed to make sure the correct libtest.dll for current build configuration
gets used when running test different tests from within the Visual Studio debugger.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-testdriver-test property sheet added to the project:
MONO_TESTDRIVER_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
* Visual Studio project to test/debug nunit tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run nunit related tests
directly from within Visual Studio.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-nunit-test property sheet added to the project:
MONO_NUNIT_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
There is also an additional user macro defined:
MONO_NUNIT_FIXTURE
This can be used to limit the number of nunit test run within a test suite.
|
|
All projects will inherit the RuntimeLibrary from mono.props where it now
can be controlled using a user property, MONO_USE_STATIC_C_RUNTIME.
|
|
|
|
|
|
* Updated vs project files to resolve winsock, winsock2 build dependecies.
* Added vs project running basic mono-mini regression tests.
|
|
naming conflicts when linking.
|
|
|
|
* Added support for user macros in order to set build/install/sgen.
* Added support for more arguments to bat files + support for quoted paths.
* Added support for verbose/quite output in bat files.
* Moved libmono xcopy post build step into separate bat file.
* Cleaned some sgen configs still left in vcxprojs.
|
|
* Enabled build target suffix in order to lable a build (primarly for sgen).
* Enabled separate build tree.
* Dropped all sgen configurations, replaced by properties and target suffix.
* Fixed pdb naming of intermediate pdb files.
|
|
* Added package/install targets.
* Moved sgen into separate library.
* SGEN set as default GC for build (used GC controlled through mono.props).
|
|
* Upgraded all projects to new vs2015 tool chain.
* Used mono.props through property manager instead of import.
* Fixed dependencies to be more explicitly in additional dependecies.
* Fixed error in mono.props, switched $ to % when referencing internal variables.
* Added property variables for includes and libraries, defined in mono.props.
|
|
|
|
This has not been supported for a while, so remove it.
|
|
|
|
Update project files with newly
added/removed sources.
|
|
(macro redefinition). The former occurs becase we mark exported function declarations using MONO_API, but not the definitions. The latter occurs because we define _WINSOCKAPI_.
|
|
problems when windows.h is included before winsock2.h: http://stackoverflow.com/questions/1372480/c-redefinition-header-files.
|
|
some new sgen files.
|
|
libmonoruntime seperate from libmono. Initial work on building sgen enabled mono with VS.
|
