| Age | Commit message (Collapse) | Author |
|---|
|
monterey (#21326)
New MacOS Monterey is not correctly resolving dylib locations when dllmap configuration is not specifying full paths, this makes VS4Mac use libcairo-2.dll from a dependency of a installed library in Hombrew.
A workaround was set full path to libcairo-2 and this fixed the problem.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
|
|
* Suppress CredScan checking
* Add justification
* One more file to suppress
|
|
* CredScan issue - remove hardcoded password
Remove commented out lines of code which had a hardcoded password flagged by the CredScan tool (line 86)
* update net_4_)/web.config file
* update net_1_1\machine.config
* update net_4_5/web.config
* update net_2_0/web.config
|
|
[lldb] another fix for handling interp frames
And improved error message in case it breaks again.
|
|
[lldb] use mono_method_full_name helper
Instead of:
```
(lldb) mbt 20
* thread #11
* frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
frame #3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
frame #4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
frame #5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
frame #6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
frame #7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
frame #8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
frame #9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
frame #10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
frame #11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
Messaging::void_objc_msgSendSuper @ 388435850 "calli.nat.fast" || frame #12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
ObjCExceptionTest::InvokeManagedExceptionThrower @ 388435752 "vcall" || frame #13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
ExceptionsTest::ManagedExceptionPassthrough @ 388502134 "vcallvirt.fast" || frame #14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
Object::runtime_invoke_direct_void__this__ @ 388462550 "vcall" || frame #15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
frame #16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
frame #17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
frame #18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
frame #19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```
It prints now:
```
(lldb) mbt 20
* thread #11
* frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
frame #3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
frame #4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
frame #5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
frame #6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
frame #7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
frame #8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
frame #9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
frame #10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
frame #11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
(wrapper managed-to-native) ApiDefinition.Messaging:void_objc_msgSendSuper (intptr,intptr) @ 388435850 "calli.nat.fast" || frame #12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
Bindings.Test.ObjCExceptionTest:InvokeManagedExceptionThrower () @ 388435752 "vcall" || frame #13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
MonoTouchFixtures.ObjCRuntime.ExceptionsTest:ManagedExceptionPassthrough () @ 388502134 "vcallvirt.fast" || frame #14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
(wrapper runtime-invoke) object:runtime_invoke_direct_void__this__ (object,intptr,intptr,intptr) @ 388462550 "vcall" || frame #15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
frame #16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
frame #17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
frame #18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
frame #19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```
<!--
Thank you for your Pull Request!
If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed.
Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number
-->
|
|
* Allow using SysV-style sonames on AIX/PASE
This uses a far saner naming convention with libtool, and is
consistent with the official PASE RPM repository. However, some
loader changes are required to make it "just work" and workaround
some real dumb behaviour on AIX's part.
Note that while Mono works when built without the different soname
tweak, it won't when installed, because the convention is strange
and the libtool .la archives won't be installed. It's recommended
as such that installation of Mono keeps the libtool files or just
uses SVR4 sonames like the rest of the world, even if they're made
strange like AIX.
* Specify a specific version of unixODBC, make an include
A workaround against PASE RPMs of unixODBC not including the just
"libodbc.so" except in the development version. If a platform needs
a specific version (the macOS reference not changed in the DllMap)
then it can be specified in the configure script.
AIX doesn't need a special name because both AIX Toolbox and Perzl
include non-archive libraries in /opt/freeware/lib - unexpected.
* Don't try to use shm_open on PASE due to it not being implemented
All this will do is cause a coredump if running the script on PASE,
and write an entry to the SLIC diagnostic logs. This test could be
re-enabled if i 7.4 supports it properly.
* fix ODBC include
* Check for what library to use for libintl when dlopenning on AIX
These checks are for the benefit of the DllMap. The construct used
is kinda hacky, IMHO, but it resolves the concerns of hardcoding.
In the event that this doesn't work (it does for me), it falls back
to what the IBM RPMs seem to use for linking gettext et al.
Not sure of the utility for other platforms, since they usually
use sane soname conventions and the one-liner here depends heavily
on an AIX developer tool and its output format.
The use of cut/awk should work with the stock AIX utils, no GNU
necessarily needed.
|
|
|
|
* Remove nunit24 from mono build and tree
* More cleanup
* Fix build
* [csproj] Update project files
|
|
Broke due to b6775765ed2a15d8aa5580ad420bfb78bf9b4406
|
|
|
|
The solution from https://github.com/mono/mono/pull/12725 doesn't fully work
since e.g. gacutil seems to verify the strong name.
Instead follow what we do for other keys where we don't have the private key:
add them to the machine.config pubTokenMapping list.
|
|
`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.
|
|
PAL_gssapi.c was converted to C recently in corefx but since our fork is not up to date I copied `PAL_gssapi.c` and `PAL_gssapi.h` into mono/metadata (I guess I should just cherry-pick those files to our fork).
For System.Data it will allow users to connect to sql servers using SSPI (Security Support Provider Interface).
See https://github.com/mono/mono/issues/9028 and https://github.com/mono/mono/issues/9751
on macOS (and iOS) it uses built-in GSS.framework.
on Linux it requires an additional package (`krb`) to be installed (see .NET Core prerequisites, e.g. https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x#ubuntu).
Unfortunately it's not installed on our CI yet.
|
|
Omitting positional parameters works for gdb linked to python 2.7 / 3.1+. On older systems (e.g. redhat 6, centos 6) gdb might be linked to python 2.4-2.6 or 3.0, adding parameter ordinals enables proper backtraces on those systems.
Fixes #9292.
|
|
|
|
Contributes to #7682
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=12850
FtpWebRequest used to work incorrectly with sub directories.
Let's say we have a following FTP structure
```
myserver
├── file1
└── subdir
└── file2
└── file3
```
Old behavior:
### 1) For `ftp://myserver/subdir/` printed:
```
file2
file3
```
Expected:
```
file2
file3
```
### 2) For `ftp://myserver/subdir` printed:
```
file1
subdir
```
Expected:
```
subdir/file2
subdir/file3
```
### 3) For `ftp://myserver/subdir/file2` printed:
```
file2
file3
```
Expected:
```
file2
```
With the fix in this PR it works as expected (matches netfx and netcore behaviors).
|
|
FSEvent CoreFX watcher becomes the new default for MacOS.""
This reverts commit 2174a521a3e45f6ce4db967a53edcc1ee2dd0433.
|
|
CoreFX watcher becomes the new default for MacOS."
This reverts commit f5b10f34a98bdbbdc0cb086a9240d5a7795ab7c0.
|
|
The FSEvent CoreFX watcher becomes the new default for MacOS.
|
|
|
|
|
|
|
|
```
(lldb) monobt
* thread #1
* frame #0: 0x00000001001b236e mono-sgen`interp_transform_call(td=0x00007fff5fbfd080, method=0x0000000100915a90, target_method=0x0000000000000000, domain=0x000000010090b741
frame #1: 0x00000001001a1c2e mono-sgen`generate(method=0x0000000100915a90, rtm=0x000000010382ac70, is_bb_start="\x01", generic_context=0x0000000100915ad0) + 9454 at tran8
transforming TestMonoAsyncGenerics::AsyncWithAwait || frame #2: 0x000000010019f553 mono-sgen`mono_interp_transform_method(runtime_method=0x000000010382ac70, context=0x004
TestMonoAsyncGenerics::AsyncWithAwait @ 0 || frame #3: 0x000000010018a178 mono-sgen`ves_exec_method_with_context(frame=0x00007fff5fbfe290, context=0x00007fff5fbfe3a8) +9
TestMonoAsyncGenerics::Main @ 12 "pop" || frame #4: 0x000000010018b4b1 mono-sgen`ves_exec_method_with_context(frame=0x00007fff5fbfe420, context=0x00007fff5fbfe3a8) + 5081
frame #5: 0x0000000100189e43 mono-sgen`mono_interp_runtime_invoke(method=0x000000010090ce38, obj=0x0000000000000000, params=0x00007fff5fbfea40, exc=0x0000000000000000, e0
frame #6: 0x00000001000164a2 mono-sgen`mono_jit_runtime_invoke(method=0x000000010090ce38, obj=0x0000000000000000, params=0x00007fff5fbfea40, exc=0x0000000000000000, erro1
frame #7: 0x000000010038b2b5 mono-sgen`do_runtime_invoke(method=0x000000010090ce38, obj=0x0000000000000000, params=0x00007fff5fbfea40, exc=0x0000000000000000, error=0x002
frame #8: 0x0000000100384e97 mono-sgen`mono_runtime_invoke_checked(method=0x000000010090ce38, obj=0x0000000000000000, params=0x00007fff5fbfea40, error=0x00007fff5fbfeb000
frame #9: 0x000000010038f335 mono-sgen`do_exec_main_checked(method=0x000000010090ce38, args=0x00000001020003c8, error=0x00007fff5fbfeb00) + 197 at object.c:4672
frame #10: 0x000000010038dd5c mono-sgen`mono_runtime_exec_main_checked(method=0x000000010090ce38, args=0x00000001020003c8, error=0x00007fff5fbfeb00) + 76 at object.c:4773
frame #11: 0x000000010038ddbf mono-sgen`mono_runtime_run_main_checked(method=0x000000010090ce38, argc=1, argv=0x00007fff5fbfef68, error=0x00007fff5fbfeb00) + 79 at objec2
frame #12: 0x00000001000d9a33 mono-sgen`mono_jit_exec(domain=0x000000010090b740, assembly=0x0000000100913610, argc=1, argv=0x00007fff5fbfef68) + 403 at driver.c:1029
frame #13: 0x00000001000dd9da mono-sgen`main_thread_handler(user_data=0x00007fff5fbfeea0) + 538 at driver.c:1098
frame #14: 0x00000001000dc21c mono-sgen`mono_main(argc=3, argv=0x00007fff5fbfef58) + 8636 at driver.c:2163
frame #15: 0x0000000100001b9e mono-sgen`mono_main_with_options(argc=3, argv=0x00007fff5fbfef58) + 46 at main.c:45
frame #16: 0x00000001000012dd mono-sgen`main(argc=3, argv=0x00007fff5fbfef58) + 77 at main.c:338
frame #17: 0x00007fffc2e66255 libdyld.dylib`start + 1
frame #18: 0x00007fffc2e66255 libdyld.dylib`start + 1
```
|
|
This allows centralized configuration of library paths. For instance,
previously setting path to libgtk-x11-2.0 won't make all parts of Mono use
provided library.
|
|
|
|
|
|
|
|
* [btls] Convert BTLS icalls to pinvokes by invoking them using [DllImport("__Internal")], which will make it easier to redirect them to a separate dylib in the future.
* [btls] Add a --enable-dynamic-btls configure flag to enable compiling btls into a separate shared library instead of embedding it into the runtime.
|
|
|
|
They weren't updated in the last 6 years and aren't helpful anymore (e.g. by causing unrelated matches during git grep searches).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We use client callbacks from the binary protocol functions. There are some DTrace probes
which we don't have binary protocol entries for. Since DTrace isn't properly supported
anyway (and doesn't even work as it should on OSX), we just remove those probes instead
of making new binary protocol entries.
|
|
|
|
This line of code would cause an error to pop up in gdb when starting.
|
|
|
|
|
|
printing some runtime types is supported.
|
|
|
|
|
|
|
|
Fix build with lib64 folder for arch-specific libraries
|
|
The changes from 3408b8e5f194774e529e223173d68a1a8f880ea5 cause
regressions in distros which do not use lib as folder for
arch-specific libraries, like Fedora x86_64.
Instead, reloc_libdir should be used (as in data/mono.pc.in).
This change is released under the MIT/X11 license.
|
|
|
|
Since libgdiplus is not installed together with Mono, it should not be
assumed to be in the same prefix.
The new policy for the --with-libgdiplus configure option is the
following:
- --with-libgdiplus=/absolute/path/to/libgdiplus.{so,dylib}
both during build/check and after installation Mono will try to use
the specified libgdiplus library; the rationale is that when an
absolute path is given, it can be assumed to be the full path to
the library that is already installed (possibly in a non-default
path).
- default, --with-libgdiplus=no, --with-libgdiplus=installed
both during build/check and after installation Mono will try to use
a system-wide libgdiplus library, that is assumed to reside in the
paths that are automatically searched by the dynamic linker; the
library is supposed to be already installed in the default path and
to be useable both during the build and afterwards.
- --with-libgdiplus=sibling, --with-libgdiplus=yes
during build/check Mono will try to use the libgdiplus library that
is assumed to be in the sibling folder (../libgdiplus), but after
the installation it will try to use a system-wide libgdiplus
library, that should be in the paths that are automatically
searched by the dynamic linker; the assumption is that the library
is not yet installed, but it will go to the default prefix after
installing it.
- --with-libgdiplus=../some/relative/path/to/libgdiplus.{so,dylib,la}
during build/check Mono will try to use the specified libgdiplus
library, but after the installation it will try to use a
system-wide libgdiplus library, that should be in the paths that
are automatically searched by the dynamic linker; the assumption is
that the library is not yet installed, but it will go to the
default prefix after installing it.
|
