| Age | Commit message (Collapse) | Author |
|---|
|
Accessing the storage account fails now when using plain http.
|
|
For some reason it recently fails with weird race conditions, let's see if that helps.
|
|
Co-authored-by: Andy Savage <45369568+andy-noisyduck@users.noreply.github.com>
|
|
They need to be CRLF otherwise we'll get conflicts when moving into dotnet/runtime which has a .gitattributes setting forcing .bat to CRLF.
|
|
|
|
|
|
Changes will default Windows SDK version as well as Platform Toolset to
the default versions used in the targeted VS version. If the projects are
opened up in VS2015, it should default to Windows SDK 8.1 and v140, but if
the same projects are opened in VS2019, it will default to latest Windows SDK 10
and v142. This way the project files should adapt to used VS version, meaning
that we could still build them using VS2015 (what's currently used on CI) but also
using VS2017 and VS2019. There should not be a need to install any previous versions
of build tools, unless an older version is targeted. It is also possible to set
PlatformToolset when calling msbuild and that should adapt to corresponding default
Windows SDK version for targeted toolset version.
Commit makes many changes and adjustments, aligning all vcxproj files but changes
should not affect build output.
|
|
* fix Enable llvm asserts
* fix chmod
|
|
* Build MSVC only runtime using make file system.
Add a new option to only build MSVC version of mono runtime and native
tools, --enable-msvc-only. In the past, --enable-msvc build both
mingw as well as MSVC runtime, this commit adds an option to only build
MSVC version of runtime and native tools using make file system.
Commit updates all native make file making sure mingw/gcc builds are
not done if --enable-msvc-only has been used. It also makes sure we
build and use MSVC based tools as part of build and tests.
Result will be a build without any mingw/gcc artifacts, but where all
existing make files still works with the MSVC build artifacts.
This commits is also preparing to switch the .NETCore build over to use
MSVC build runtime in order to get LLVM support, something that is
currently only supported on Windows MSVC build.
* Add link to mono-sgen.exe and clean windows binaries.
* Fix failures in mono/tests test-aot on Windows.
* Add fullaot-mixed tests on Windows x64.
* Run msbuild in parallel.
* Default to x64 mingw host on cygwin build.
|
|
* Fix linking of OS-provided zlib
This is a reduced version of https://github.com/mono/mono/pull/16091
without the Z_PREFIX stuff
* Get rid of HAVE_ZLIB, be explicit about HAVE_SYS_ZLIB vs HAVE_STATIC_ZLIB
* Proposed fixes from Alex
|
|
We used to use the static MXE toolchain, but after switching to Homebrew, we
have to explicitly pass flags to build binaries that don't depend on the
MinGW32 GCC support libraries (libstdc++-6.dll, libwinpthread-1.dll and others)
when building the LLVM and Mono binaries.
The simplest approach is just to pass CMAKE_EXE_LINKER_FLAGS=-static to cmake
and LDFLAGS=-all-static to libtool. The rest of the changes are just to make
it easier to do that by adding a configure flag and updating the SDKs
infrastructure.
We will also need an LLVM bump to actually build a new llvm archive with the
new build flags; until then, building Mono will provision an old build of LLVM
with the old build flags that still depends on libstdc++-6.dll.
---
An alternative approach instead of passing -all-static and -static would be to
probe for the assorted -static-libXYZ flags to GCC at configure time. (For the
LLVM build we would need to hardcode them as that build doesn't go through
autoconf). Right now Mono doesn't have any other DLL dependencies (other than
the core windows DLLs), so -all-static works just as well and is simpler.
|
|
|
|
|
|
|
|
It turns out that homebrew now has a package for the MinGW gcc-based windows
cross compiler which is awesome as it allows us to skip building MXE and use the
latest version of the GCC suite pre-packaged for Mac. This commit removes almost
all traces of MXE (except for `mxe.mk` itself, because I don't know if any bot
or external tool, whatever, use targets in it) and adds the following brew
packages to SDK bot provisioning as well as to the `provision-mxe` target of
Mono SDKs:
* mingw-w64
* xamarin/xamarin-android-windeps/mingw-zlib
The latter package builds a Windows version of zlib using MinGW and it comes
from Xamarin's own homebrew tap at https://github.com/xamarin/homebrew-xamarin-android-windeps/blob/f4cc90845ff1953800d8d71035566a12d9b7aa24/mingw-zlib.rb
Additionally, this commit adds a new `configure` flag: `--with-static-zlib=PATH`
which allows one to specify the static zlib archive to use when linking Mono.
The static archive supersedes the otherwise indicated or detected zlib. This is
the recommended mode of operation for MinGW builds as it avoids problems with
`zlib.dll` versions on the target machine.
|
|
* [safepoint] Use LLVM pass to insert safepoint
This is to avoid safepoints to stop optimizations from happening.
* [safepoint] Use LLVM pass to insert safepoint
This is to avoid safepoints to stop optimizations from happening.
* fix error: emit_gc_safepoint_poll does not return anything
* Revert partial 4150f06f8621f2f2918e3bd747bf80a0f0f8c9c6
* Fix build
* [runtime] Add mono_threads_state_poll to preinited icalls
* [runtime] Adding back in safepoint icall skip code
* Revert mini.c to 100f422
* [runtime] Add missing deref to safepoint poll
* [runtime] Make safepoint functions have WeakODR linkage
|
|
* [ci] Fix Linux x64 Bitcode job
* [ci] Add Bitcode+Interpreter job
* [ci] Improve output information when AOTting the BCL
|
|
* [mini] Use C++ linker iff building C++ that needs the C++ runtime
(This has nothing to do with --enable-cxx. This is about our LLVM .cpp files).
Explicitly set the linker for libmini. The issue is that the automatic
linker selection (See
https://www.gnu.org/software/automake/manual/html_node/How-the-Linker-is-Chosen.html)
looks at all the _SOURCES for a target, even those that are only
conditionally added, even if the condition is false. So because we sometimes
build mini-llvm-cpp.cpp we always get the c++ linker. But that's not what we
want.
The goal is:
- if there's any C++ code included into mono (either the shared lib or a
program) that needs the C++ runtime library, ensure that we link using the C++
linker. This was already true, we just need to make sure it stays true.
- if mono is built in such a way that it has no C++ code in it (that needs the
C++ runtime library), ensure that we link with the C linker and without
including the C++ runtime library.
This will address issues like https://github.com/mono/mono/issues/12060
We do this in two steps:
1. We split out all the c++ source code to libmini-cxx.la and include that into
libmini.la.
That's enough to force C++ linking if libmini-cxx.la has any code in it. If
there's no C++ code (right now that means there's no --enable-llvm or
--enable-llvm-runtime), we don't add libmini-cxx.la and all the C source in
libmini links in the normal manner.
2. We have a hack where we sometimes include libmono.a (the static library)
into the mono executable. In that case, we could forget about the C++
linker (which leads to build failures because llvm uses all the C++ runtime
library stuff that we forgot to link in).
So we use the "nodist_EXTRA_..._SOURCES=dummy.cpp` hack to make it look like
the mono executable has C++ source, which in turn forces the use of the C++
linker.
The conditional logic here has to match exactly what we do for deciding
whether to add libmini-cxx.la into libmini.la. If we do, then force the use
the C++ linker here.
It may seem like another option is to use something like
`mono_boehm_LINK=$(CXXLINK)` to set a target-specific linker. But this is
bad, actually, because in that case we will drop the `..._LDFLAGS` and other
linker flags unless we're very diligent to include all of them. The
`nodist_EXTRA_..._SOURCES` hack is more resilient because automake will
ensure that all the flags are kept.
* [llvm,wasm] Don't add -lstdc++ in llvm_config.mk
Leave it to the linker.
This is needed when building wasm cross compilers for windows which pass
-static-libstdc++ to configure. As a result we would get duplicate symbols by
linking against a static libstdc++.a and also the export stubs of libstdc++.dll
In mini, link monow using the C++ linker same as with mono by using the nodist_EXTRA_..._SOURCES
trick.
In wasm, pass -static-libstdc++ to CXXFLAGS, not LDFLAGS. c++ linking picks up
CXXFLAGS anyway, and -static-libstdc++ has no effect on the C linker and it
doesn't affect explicit -lstdc++ flags anyway.
|
|
Mono doesn't use libxml2 and neither do the LLVM bits used by Mono when building
the AOT cross-compilers. Presence of `-lxml2` on the command line breaks 32-bit
builds on 64-bit Linux hosts:
libtool: link: cc -shared -fPIC -DPIC -Wl,--whole-archive ./.libs/libmini.a ./.libs/libmono-ee-interp.a ./.libs/libmono-dbg.a ../../mono/metadata/.libs/libmonoruntimesgen.a ../../mono/sgen/.libs/libmonosgen.a ../../mono/utils/.libs/libmonoutils.a ../../mono/eglib/.libs/libeglib.a -Wl,--no-whole-archive -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMMCParser -lLLVMMC -lLLVMBitReader -lLLVMCore -lLLVMBinaryFormat -lLLVMSupport -lLLVMDemangle -L$HOME/xamarin-android/external/mono/sdks/out/llvm-llvm32/lib -lz -ltinfo -lxml2 -lstdc++ -lm -lrt -ldl -lpthread -O0 -ggdb3 -m32 -g -mno-tls-direct-seg-refs -Wl,-export-dynamic -Wl,-soname -Wl,libmonosgen-2.0.so.1 -o .libs/libmonosgen-2.0.so.1.0.0
mv -f .deps/libmini_la-aot-runtime-wasm.Tpo .deps/libmini_la-aot-runtime-wasm.Plo
/usr/bin/ld: skipping incompatible //usr/lib/x86_64-linux-gnu/libxml2.so when searching for -lxml2
/usr/bin/ld: skipping incompatible //usr/lib/x86_64-linux-gnu/libxml2.a when searching for -lxml2
/usr/bin/ld: cannot find -lxml2
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:1495: libmonosgen-2.0.la] Error 1
Installation of `libxml2-dev` (on Ubuntu/Debian + friends) for the x86
architecture (or x86_64 architecture on 32-bit host) would be possible but then
it would break the 64-bit build because the 64-bit version of the library would
be absent. It would be a problem if Mono+LLVM actually used xml2, but since it
doesn't we can just disable the feature completely.
|
|
10.13 (#11179)
This breaks when LLVM is built on 10.13+ and the runtimes are built on 10.12.
|
|
The makefile uses $(dir $<) which has `../` and so refers to `llvm/external/llvm` rather than `external/llvm` now that we're using llvm from a submodule in external/
|
|
|
|
|
|
* [sdks] Fix llvm-llvm32 build
* [wasm] Make sure we compile wasm-cross as 32bits
|
|
* Fix Mono Windows cross compiler using mono LLVM release_60 branch.
For scenario where llvm-config.exe can't be run (none WSL/CygWin build target)
Build will fallback to hard coded libraries not working with mono LLVM release_60
branch.
Added an exact mirror of what llvm-config.exe is returning for different components
on mono LLVM master and mono LLVM release_60 branch.
The selected codegen libraries (passed in as extra_libs) was not handled in any cases
so added them into the build script as well.
* Split parameter between lvm codegen libs and llvm extra libs.
Need to explicit pass -lz in case where configure have detected zlib availability
and llvm-config.exe can't be executed. In cases where zlib is not available, default
in mingw installs, this check make sure link step won't fail due to missing library.
* Fix inversion of aarch64codegen libs.
* Enable package-android-cross-{arm,arm64,x86,x86_64}-win builds on CI.
* Fix incorrect checks when compiling Windows cross compiler.
Windows cross compiler could have a target that is !TARGET_WIN32 but still
running on a Windows host, so check needs to look at !HOST_WIN32 to determine
if Unix source files can be included or not.
|
|
provisioning of LLVM for both Android and iOS. (#10445)
* [sdks] Add CrossRuntimeTemplate
* [sdks] Add cross-{arm,arm64,x86,x86_64}{,-win} runtimes for XA
* [sdks] Use CrossRuntimeTemplate for iOS
* [sdks] Factor various variables for RuntimeTemplate
* [sdks] Use MonoRuntime template for desktop-x86_64
* [sdks] Unify provisioning of LLVM for both Android and iOS.
A global CFLAGS would be set in `run-jenkins.sh`, and that would screw up with LLVM. The global CFLAGS makes sense as long as we are only building Mono, but that's not the case with LLVM anymore.
* [sdks] Remove android-armeabi, it's been removed from XA already and the target has been deprecated in the NDK
|
|
lateralusX/lateralusX/fix-cross-windows-llvm-support
Fix Windows LLVM mono cross compiler build.
|
|
This commit re-enables Windows LLVM mono cross compiler build + adjust to
new changes done in mono LLVM build system.
|
|
|
|
|
|
|
|
This reverts commit 3dd1e1d92abd6c5586dfacc81003dc5713800847.
|
|
This reverts commit 5553faffcb99228389d53fc1e0450b273b765f2e, reversing
changes made to 790e6f6ff9fa87ffaf9e94087f214b7996d5dc47.
|
|
This reverts commit bb8a7f4bda2d1e6567a8a8f0516a163f753d0ef6.
|
|
|
|
automake 1.16.1.
|
|
|
|
used by versions.mk. (#9919)
|
|
version has too many problems. (#9889)
* [sdks] Switch the 32 bit cross compilers back to the old llvm 3.6, the new version has too many problems.
* [sdks] Fix building llvm36.
|
|
[llvm] Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886.
Fixes https://github.com/mono/mono/issues/9750.
|
|
https://github.com/mono/mono/issues/9456)
|
|
|
|
|
|
|
|
|
|
We had a problem with order of operations before. Makefile.am.in is
interpolated twice in the standard build. The first time happens when
autoconf runs. The second time happens when we enter the mono/mini directory
and execute our build. In the refresh, we lose our AM_CONDITIONAL conditionals
defined that aren't also AC_DEFINE variables on linux.
That's what it's vital to define all variables in all namespaces to have maintainable
automake code.
Furthermore, some of the CFLAGS logic we defined is designed for older LLVM copies, as
it includes some flags like O3 and Wall that we don't want.
In order to not get hacky with this, I moved the logic for using llvm-config into
a bash file in /llvm that creates a makefile fragment. The logic says that this fragment
should be null on calling autoconf, and then will be instantiated after we build llvm.
This fixes the build on Linux. We can expect bash behavior to be more consistent between
OSX and Linux than we can with automake too. I think this is a reorg with good long-time
maintainability.
|
|
|
|
|
|
|
|
|
