| Age | Commit message (Collapse) | Author |
|---|
|
The plan to put additional helpers into this directory didn't materialize and we can just inline the one thing we have in common.mk where needed.
|
|
Those folders won't be present in the dotnet/runtime repository.
We need to factor out AC_OUTPUT into a separate file so we can continue
to share configure.ac but not the list of files in AC_OUTPUT since
autotools doesn't support variables there.
|
|
* Fix build on Autoconf 2.63
This was broken in e7f9dbe73c3344c96a13892a6c4c45f8e5c35aa3, because
AS_VAR_APPEND does not exist until v2.63b (?!)
* Work around autoconf for Mac not being fit for purpose
The correct way to do this is with AC_DEFUN in a special m4 file
But this dies on Mac, because reasons.
See also https://github.com/jedisct1/libsodium/issues/217
|
|
Advantages:
Dynamic linker gets out of the way of random function calls,
in terms of timing, in terms of locking, and in term of success,
and possibly in terms of security (readonly function pointers).
If you successfully load, then you can make function calls with impunity,
without regard as to if they are in the same .so as the caller, well,
assuming they are to a leaf like libc, or to something itself built with -z now.
The "success" is significant, as otherwise loaded LLVM has unresolved symbols lurking, depending on which code paths you send it down.
Disadvantage: Slower startup.
Mixed:
Platform consistency, since this is how Windows behaves usually (unless you say link /delayload)
This will combine well with an upcoming revision of https://github.com/mono/mono/pull/14524.
Difficult alternative: Force the binding along sensitive paths by calling their callees earlier.
Typical alternative: Ignore the matter.
Android: It is believed this switch produces a warning, which is ignored, there is no affect, and it is unclear if the behavior is actually "now" or "lazy". Logs could be checked and a test run, but neither.
|
|
`Mono.Native` is the new name for both `System.Native` and `System.Security.Cryptography.Apple`.
It is built as a stand-alone shared library and not bundled with the runtime because we
may need to build two different versions of it.
Starting with macOS 10.12+ and iOS 10+, Apple introduced a new Unified API for some of the
crypto primitives that we're using as part of System.Security.Cryptography.Apple.
On Desktop, we can check at runtime whether the OS version is recent enough and switch
implementation accordingly. We build a single `libmono_native` shared library.
However, on Mobile we cannot have any undefined symbols as this would break Bitcode.
During the mobile build, we are called with `CC` containing an explicit minium version flag,
which is either `-mmacosx-version-min=`, `-mios-simulator-version-min=` or `-miphoneos-version-min=`
depending on platform.
We build two versions of the shared library:
- `libmono_native_compat` is built with whichever minimum version is passed to us via `CC`.
- `libmono_native_unifed` is built with the minimum version set to macOS 10.12+ / iOS 10+.
For testing purposes, there is a function called `mono_native_get_platform_type ()`
(see mono/native/mono-native-platform.c), which returns a `MonoNativePlatformType` enum value.
There is also `Mono.MonoNativePlatform.GetPlatformType ()` (see mcs/class/corlib/Mono/MonoNativePlatform.cs).
This can be called by automated tests both to ensure that the library has been correctly installed and also
to verify that it's the correct version of it.
* `configure.ac`: add new configure checks for Mono.Native.
* `mono/native/`: new directory - this replaces the `System.Native` code that was previously in `mono/metadata`.
* `mcs/class/corlib/Mono`: New internal `MonoNativePlatformType` and `MonoNativePlatform` classes.
|
|
iconv.m4 was deleted in https://github.com/mono/mono/commit/ff40ceff387e1b4a726a00a4e4d0e654afe1cd99
|
|
It is enough to check for iconv
dependencies once in the eglib/configure
- just use the generated libtool
library file to automatically
add additional dependencies (if any).
While here, make sue libeglib.a
has libraries returned by LTLIBTOOL
as a libtool dependency.
|
|
It should work with earlier versions too and prevent issues like
https://lists.dot.net/pipermail/mono-devel-list/2018-February/044638.html
|
|
This commit implements checking whether the compiler used to build mono supports
the recently added switches to generate code designed to mitigate the effects of
the Spectre/Meltdown bugs of the modern CPUs (https://meltdownattack.com/).
As of this commit the options are implemented for GCC 8.x, 7.3 and backported to
some older versions of gcc 7.x (e.g. in Ubuntu). The options tested for, and
used, here are:
-mindirect-branch (https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#index--mindirect-branch)
-mfunction-return (https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#index--mfunction-return)
Checks and usage of the above flags is hidden behind the
`--with-spectre-mitigation` configure option, defaulting to `no`.
Two additional options are implemented to specify the kind of thunk to implement
by each of the flags above:
--with-spectre-indirect-branch-choice=keep,thunk,inline,extern
Convert indirect branches to the specified kind of thunk (defaults to inline)
--with-spectre-function-return-choice=keep,thunk,inline,extern
Convert function return instructions to the specified kind of
thunk (defaults to inline)
|
|
|
|
obsoleted by automake.
|
|
|
|
|
|
|
|
|
|
|
