| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit ac0f7ece3511837a6dd4c8465dbf3a07d783a155)
|
|
(cherry picked from commit 362eface2cd657e292c38d1da1c50833c353cdd9)
|
|
System.Drawing.Common (#13425)
Backport of #13414 to 2019-02.
Incorporates drawing-specific changes from #13198 and #13326 and ports them to 2019-02.
|
|
(cherry picked from commit 602bdea38529fbe2a6c7d192efd06ade5f5566c1)
|
|
(#13042)
Correct access permissions for run-msbuild.sh. Adding "user execute" seems to fix the following build error. With this change I'm able to build on windows in Cygwin. without, I see the below error:
```
$ make -j4
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /cygdrive/c/mono/mono/missing autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
Git submodules updated successfully
make all-recursive
make[1]: Entering directory '/cygdrive/c/mono/mono'
Making all in msvc
make[2]: Entering directory '/cygdrive/c/mono/mono/msvc'
Building Mono runtime using Visual Studio.
../msvc/run-msbuild.sh "build" "i686"
**/bin/sh: ../msvc/run-msbuild.sh: Permission denied**
make[2]: *** [Makefile:614: all-local] Error 126
make[2]: Leaving directory '/cygdrive/c/mono/mono/msvc'
make[1]: *** [Makefile:583: all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/c/mono/mono'
make: *** [Makefile:513: all] Error 2
```
(cherry picked from commit fe7c3d43e5c40a5918223ae4ef2189ffb275c4ae)
|
|
Add support for building Windows x64 fullaot version of winaot profile
that can be run on CI. Initial changes also add execution of mini regression
tests on CI. More tests will be added going forward and when having full
pass rate.
Add support for building Windows x64 fullaot+llvm version of winaot profile
that can be run on CI. Initial changes also add execution of mini regression
tests on CI. More tests will be added going forward and when having full
pass rate.
In order to get deterministic build results and working build on CI, we need
to setup a correct build environment for the MSVC builds. Since MSVC build is
currently run from cygwin, there are environment problems, both general
but also in our CI environment, since we add cygwin bin folder to system path
(needed by Jenkins plugin). When running more complex cmake builds like
BTLS and LLVM, this will cause problems picking up incorrect tools,
failing builds on CI.
Another problem is the AOT compilation using MSVC toolchain. In the
past CI used some "hard coded paths" to make sure clang.exe and link.exe was found.
This is not optimal and won't work when including LLVM as part of full AOT since
link.exe will need access to more of the full build environment setup by VS
development environments (like platform libraries).
In order to get a better build environment on CI this commit includes and enhance
a couple of build scripts used to run msbuild.exe and mono-sgen.exe (as AOT compiler)
in a VS development environment, isolate that build process from cygwin environment.
The build scripts will locate installed VS tooling, VS2015 build tools or VS dev env,
VS2017 build tools or VS dev env and use corresponding development environment
scripts as part of running msbuild.exe and mono-sgen.exe in AOT mode.
In order to make sure mono-sgen.exe as AOT compiler is run through these scripts
an additional environment variable MONO_EXECUTABLE_WRAPPER is introduced and used
in mono-wrapper when set. Without this indirection there will be problems on CI
tests since the environment is using MONO_EXECUTABLE and pass that into for example
test driver that run child processes of mono-sgen.exe, meaning that we can't
use scripts for MONO_EXECUTABLE, but splitting the MONO_EXECUTABLE to represent
mono runtime and have a MONO_EXECUTABLE_WRAPPER that could be a launch script
solves this issue.
This commit also includes several smaller fixes made to the generic
fullaot build infrastructure.
Fix additional msbuild arguments.
Add Mono.SIMD assembly to winaot profile.
Run msbuild.exe as part of .bat file.
|
|
file. (#12436)
* [llvmonly] Move all runtime support code to a new llvmonly-runtime.c file.
* [llvmonly] Make mini_init_delegate () work in mixed mode, it needs to initialize both the interp and the llvmonly related data.
* [llvmonly] Implement EH support in mixed mode.
On interp->native transitions, add a try-catch. On native->interp transitions, rethrow the exception using a c++ throw.
* [llvmonly] Unify function naming, name all llvmonly runtime functions mini_llvmonly_.
* Fix a build failure.
* Fix windows build.
* Fix an aot failure.
* Fix the EH changes.
|
|
lateralusX/lateralusX/fix-warning-errors-win64-platform
Fix warning and build errors triggered in win64 platform that doesn't define HAVE_CLASSIC_WINAPI_SUPPORT.
|
|
Source Link allows IDEs/debuggers to retrieve a source file from a remote location like GitHub when the local file isn't available.
Specification: https://github.com/dotnet/designs/blob/e55c517a1e7f8dc35b092397058029531209d610/accepted/diagnostics/source-link.md
For now we only embed info about mono, cecil, corefx and corert since that covers 99% of what you usually want to debug and doesn't need fancy logic that reads git submodules and figures out their URLs.
Should enable use cases like https://twitter.com/jlaban/status/1084248087802060801
|
|
|
|
platforms.
Several of the name changes fixes MSVC warnings where local variables
hides global variables using the same name.
Number of adjustments not building on platforms not defining HAVE_CLASSIC_WINAPI_SUPPORT.
Fix a couple of build projects not setting dependencies on build-init.vcxproj.
This could cause races in build order if projects depend on build initialization.
Added support to force external builds to use msbuild even if ninja is present.
|
|
macOS was used for checking HostPlatform for OSX, but darwin is what the value was set to. This fixes the solution and csproj files for OSX.
|
|
The gensources tool now supports platform/specific .sources for nunit and xunit tests.
|
|
(#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.
|
|
CC libtest_la-libtest.lo
<inline asm>:37:2: error: instruction requires: Not 64-bit mode
popl %eax
^
... same error many times
Fix ThisCall tests.
Libtest.c needs to be C++ for Visual C+++ to accept __thiscall.
gcc accepts __thiscall in C.
Visual C++ only accepts __thiscall on member functions and function pointers,
not globals. Gcc accepts on globals also.
So test what we can.
add extern C
Limit thiscall testing to Win32, even if gcc has more support.
|
|
Windows x64 LLVM 6.0 support.
|
|
* [jit] Refactor the constrained call handling code into a separate function. NFC.
* [jit] Move the low level call related code to calls.c. NFC.
* [jit] Use mini_emit_get_rgctx_klass () in a few more places.
* [jit] Add calls.c to common_sources.
* Fix some c++-isms.
* Fix the windows build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
* Integrate msvc build into make build system.
Add support to perform msvc build as part of regular make build. By default
msvc build will not automatically be done and needs to be enabled using
--with-msvc argument passed to ./autogen.sh. Doing msvc build as part of
regular make will automatically set MONO_EXECUTABLE to build msvc build
Mono runtime used in BCL and Test build as well as runtime used when running
tests.
* Add support to install msvc build mono runtime.
* Disable --with-msvc argument for none Windows builds.
* Fix VS2015 Build Tools build environment.
* Updated with review feedback switching to --enable-msvc.
|
|
In general this is achieved by renaming mono_foo to mono_foo_internal,
and mono_foo_bar calls mono_foo_bar_internal, possibly adding a GC mode change
to mono_foo_bar and removing from mono_foo_bar_internal.
We can also consider other names like m_foo_bar, mi_foo_bar, m.foo_bar, m->foo_bar, m::foo_bar, using mi = mono_internal; mi::foo, foo.bar(), etc.
* [test] Report dlsym failure with an assertion failure and give the symbol.
* Compilation of external-only.c/.o needs special care.
Because it is dead code, except for exports, the linker does not necessarily eagerly look into it (.o within .a), and export anything. This is the usual behavior of Windows linker. Unix linker I guess it varies between programs and shared libraries, but it was observed and broke a test, and a small case was constructed to demonstrate the behavior (i.e. where the dlsym assert is added), even though I assumed the opposite -- so must be program vs. sharedlibrary.
Therefore, we `#include external-only.c` in object.c.
Longer term we should probably use Windows .def files and their Unix equivalent, and/or be sure to list external-only.o directly on the link command line, instead of burying it in a static library.
.def files were used in the past and have other advantages/differences.
Other than guaranteeably reaching into .a/.lib files to find exports, they also export on NT/x86 as plain "mono_foo" instead of "_mono_foo", easing portability of LoadLibrary / GetProcAddress.
The loss of the x86 C name mangling *could* be viewed as a loss, of a tiny amount of safety.
They also make declspec(dllimport) and declspec(dllexport) both pointless, at least for C functions -- dllimport remains significant for data and C++ (no need to list mangled names in .def file), and to microoptimize one instruction out of some calls on non-LTCG builds.
|
|
* Add support for BTLS assembler build on Windows (cygwin/msvc).
Building BTLS with assembler support on Windows requires several
additional build tools (except cmake) for both cygwin/msvc builds.
On cygwin, perl and yasm will be needed and on msvc, ninja, perl
and yasm. On msvc builds BTLS doesn’t support Visual Studio generator
when building with assembler support, so this commit adds support for
ninja build system covering that scenario. This commit adds support for
auto detection of needed build tools and enable assembler builds if all
needed tools have been identified as available. Commit also fixes the
execution of msbuild on CI to just use the original PATH variable instead
of the cygwin PATH to make sure correct version of identified build tools
gets used (Windows version of git, ninja, perl and yasm). Both cygwin and
msvc build will use nasm compiler (through use of yasm) since generated
assembler won’t compile with mingw’s gcc version.
* Bump BTLS commit.
* Fix a couple of warnings on BTLS build.
* Fix failing certificate import test using BTLS on Windows.
Mono BTLS library assumes all passwords are ANSI encoded strings since
SafePasswordHandle gets passed directly through pinvokes. This is only true for
SafePasswordHandle implemented on Unix:es. On Windows, SafePasswordHandle stores
passwords as Unicode, most likely due to Windows Crypto API accepting Unicode
passwords. When using BTLS on Windows this difference submerged since passwords
passed to BTLS will be Unicode encoded failing the decryption of PCKS12 structure.
Keeping the pattern already in place, passing SafePasswordHandler all the way
through pinvokes, the needed conversion will be done just before calling into OpenSSL
library as part of mono's BTLS library adapter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* [build] Unify bootstrap profiles
We can now rely on build only as we have reliable monolite and package
compilers
* Fixes genproj dependencies
* [csproj] Update project files
|
|
mono-math.h. (#10830)
MONO_API here was dubious, as all systems have it, except Visual C++ was configured away.
In Visual C++, it is in ucrt, so present in 2015 also.
More information in nearby comments.
|
|
(#10764)
This PR cleanups C++SDKs support and gets them all passing for the first time, esp. Android (WebAssembly already was, iOS uncertain before, green here).
* Current Visual C++ has signbit.
* Rework C++ linkage to C99 math-- trunc, isnan, isinf, etc.
Go through mono wrappers that are compiled as C.
Remove support for Visual C++ pre-2015 and non-C99 Solaris.
(Solaris has plenty of other problems compiling.)
Cleanup Windows ssize_t support.
* Remove trunc and aintl autoconfigury.
Use trunc unconditionally. (aintl is a Solaris near equivalent to trunc).
* Replace dis_isnan with mono_isnan.
* Interpreter already assumes presence of isinf and isfinite, so everywhere else might as well too.
A fair amount of cleanup therefore -- autoconf, ifdef, etc.
If this changes back, the mono_isinf, etc. wrappers are likely, but not necessarily, where to handle it for everyone, not sprinkling ifdefs and alternate implementations around -- assuming all users want the same fallback.
As well, we might want to import some good BSD libc versions of all these if there is any remaining question of portability. *Everyone* except old VAX and Cray have always used the same 32bit float and 64bit double representations since circa 1985 so these are all probably about one line of portable C89/C++98 each, maybe with endian sensitivity.
|
|
mono_domain_try_type_resolve_typebuilder, mono_domain_try_type_resolve, mono_domain_try_type_resolve_name. (#10675)
* Convert or partially convert mono_domain_try_type_resolve_typebuilder, mono_domain_try_type_resolve, mono_domain_try_type_resolve_name.
In order to use TYPED_HANDLE_DECL, this required splitting handle.h into at least two pieces,
here called handle-decl.h and handle.h.
A fair amount of early returns had to be converted.
* PR: Move mono_domain_try_type_resolve_name from domain-internals.h to reflection-internals.h.
Move mono_domain_try_type_resolve_typebuilder ditto.
Move ves_icall_TypeBuilder_create_runtime_class from object-internals.h to reflection-internals.h.
Move TYPED_HANDLE_DECL (MonoReflectionAssembly) from handle-0.h to reflection-internals.h (previously object-internals.h)
Move TYPED_HANDLE_DECL (MonoReflectionTypeBuilder) ditto.
Add MONO_HANDLE_BOOL to handle.h so we can 1. Stop inverting tests and 2. Prefer
true first in ternary.
x = MONO_HANDLE_BOOL (y) ? z : 0
instead of
x = MONO_HANDLE_IS_NULL (y) ? 0 : z
Add include "reflection-internals.h" to mono-security.c
Add include "reflection-internals.h" to security.h
object-forward.h:
Place MONO_RT_MANAGED_ATTR on MonoReflectionTypeBuilder.
Really it should just be MonoObject, and then implied
by everything that contains it.
Place MONO_RT_MANAGED_ATTR consistently.
Sort by native then managed.
mono_reflection_get_type_with_rootimage: Rename assembly to refection_assembly
and then use assembly to reduce occurences of MONO_HANDLE_GETVAL (assembly, assembly).
mono-security.c: include config.h unconditionally and just once.
* Change mono_class_get_ref_info_raw to return MonoReflectionTypeBuilder* instead of MonoObject*.
Remove casts on mono_class_get_ref_info_raw calls.
Change mono_class_get_ref_info to return MonoReflectionTypeBuilderHandle instead of MonoObjectHandle.
Move mono_class_get_ref_info from object-internals.h to reflection-internals.h.
Use mono_class_get_ref_info instead of mono_class_get_ref_info_raw.
* Cleanup -- MONO_HANDLE_BOOL and contains instead of cast.
* PR: Fix incorrect comment. Fix precise GC hole wrt invoke.
|
|
jay) (#10485)
* Fix forceBuild not working for projects with unknown platform names (i.e. jay)
* Clean up error messages
|
|
|
|
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
|
|
override it (#10429)
* Move the PreBuild dependency property later in the file so targets can't override it
* [csproj] Update project files
|
|
cil-stringreplacer (#10381)
This ensures that System.CompilerServices.Unsafe has implemented method bodies, necessary for Span and similar use cases.
|
|
* Remove use of sln dependencies and use csproj project references instead
* Rewrite jay.vcxproj so it builds correctly even without help from the sln file
* Force pre-build event to run after references are resolved. Change how culevel.exe path is computed to be more resilient.
* [csproj] Update project files
|
|
https://github.com/mono/mono/pull/10252. (#10377)
|
|
* [cxx] int vs. enum.
There are at least three or so approaches to this.
1. Sprinkle around casts.
2. Overload operators.
2a. Bit-only (| & ^ |= &= ^=) This PR.
2b. Also math (+ - ++ -- == !=)
3. typedef to int instead (https://github.com/mono/mono/pull/10231)
They all have tradeoffs.
1. Casts: The most line damage. Not huge, but the most.
2. Overloads: New idiom to some but an old idiom. Supported in this way by windows.h even.
This is the most "C++y solution".
3. int: Highest level of source compat and semantic compat. Least line damage (just
change the declarations). Least debuggable and least typesafe.
In terms of semantic compat, even in C the guarantees aren't particularly strong.
Some enums will be int, some unsigned, depending on the values and the compiler.
Perhaps even other types, but I doubt it.
I observe C++ compilers don't tend toward unsigned the same way, so switching
to C++ will on some platforms lose unsignedness. Given we didn't have it portably
anyway, should be ok.
A typesafe enum has the properties that enum A cannot be silently assigned to enum B (ok,
there might be a warning), or from an integer.
A typesafe enum, bitfield or otherwise, can/will be shown symbolically by a debugger.
(lldb does not handle bitfields, only strict enums)
A C enum might be debuggable, w/o typesafety.
A C enum can be freely mixed with other enums and integers.
A C++ enum is more restricted.
Using typedef int, is a maybe surprising option, but does provide the closest meaning to C enum.
Per guidance, this PR also changes one enum to #defines + int.
* PR: "mono" => "g"
"T" => "type"
static_cast where it works (not to reference)
Use templatized typedef instead of macro, if it works on g++4.4.
Add test.
Provide to build eglib tests.
Borrow CXXFLAGS_COMMON from https://github.com/mono/mono/pull/10271.
Add some const to test harness.
* g++4.4 compat (not quite C++11) -- use macro, not template typedef.
* Fix real problem with aliasing seen with g++4.4.
Use attribute(may_alias) when casting pointers/references.
* Add mono/eglib/test/enum.cpp.
|
|
It was removed in c16ff9ab235abef10213f49dceb5251c7d8f6efd.
|
|
|
