We already have this logic for frameworks we detect according to the namespace
of the used types, but not for frameworks we detect from P/Invokes.
Fix this by using the same framework exclusion logic for frameworks detected
from P/Invokes: don't link with frameworks not available in the current SDK.
https://bugzilla.xamarin.com/show_bug.cgi?id=59636
* [msbuild] Re-added wildcard (*) expandsion for application-identifier in Entitlements.plist (#2186)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=57119
* Bump mono (#2213)
* Framework tests were still binding non-linked Simple class which errors now (#2216) (#2218)
- Improve Makefile to rebuild when projects build with errors
* Bump mono to get cecil fix for bug #56808. (#2222)
https://bugzilla.xamarin.com/show_bug.cgi?id=56808
* [msbuild] Use @(ReferencePath) instead of @(ResolvedFiles) (#2188) (#2214)
This allows things to work on both xbuild and msbuild.
In xbuild, both lists are exactly the same and on msbuild,
only @(ReferencePath) exists.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55147
* NSActivityOptions.IdleDisplaySleepDisabled had wrong value (#2232) (#2239)
This was due to an integer overflow. The original value was based on Int32
1 << 40 == 256
The correct value should be based on a UInt64.
1UL << 40 == 1099511627776
* [tests] Fix bug 57699 - [iOS]InternalsTest failure (Linkall) tests on device (#2243)
Strip native debugging symbols should not be checked for debug builds
* Bump mono to get fix for bug #57780.
https://bugzilla.xamarin.com/show_bug.cgi?id=57780
* Update .gitmodules
Change branch to d15-3 branch of mono
* Bump maccore to get fix for bug #55064.
https://bugzilla.xamarin.com/show_bug.cgi?id=55064
* [mono] Bump mono to get the head of cecil/mono-2017-04 and fix IsComObject #57919
Also fix#58789 [1], the typo in tools/mtouch/Tuning.cs showing in MT0000 errors
instead MT2102. That's already in master and d15-4
mono bump includes:
[2] commit 2a6502cee0df9de5198eafe7c8b5f6ac25106f34 (HEAD -> d15-3, origin/d15-3)
Merge: 02457c20fcf 5e05cafc6f1
Author: Luis Aguilera <luis.aguilera@xamarin.com>
Date: Fri Aug 18 10:04:06 2017 -0400
Merge pull request #5401 from marek-safar/com
[Marshal.IsComObject] Make this predicate return false instead of thr…
[3] commit 02457c20fcf57c0610e844d638eb1da82b5d1eb0
Merge: da80840ea55 73fd9a1b82e
Author: Luis Aguilera <luis.aguilera@xamarin.com>
Date: Fri Aug 18 09:59:06 2017 -0400
Merge pull request #5400 from spouliot/bump-cecil-58834-d15-3
[cecil] Bump to the head of the mono-2017-04 branch and pick the fix for bug #58834
References
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=58789
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=57919
[3] https://bugzilla.xamarin.com/show_bug.cgi?id=58834
* [mtouch] Put 'mono_profiler_startup_log' in the symbol list. Fixes#58778. (#2501)
We need the 'mono_profiler_startup_log' symbol when profiling is enabled, so
make sure to add the symbol to the correct list of symbols we need.
Previously we were passing `-u _mono_profiler_startup_log` to clang directly,
which is fine, but not complete, since it does not write the symbol to the
symbollist file (--symbollist=file), which means it wouldn't be preserved when
the MSBuild tasks strip the executable.
https://bugzilla.xamarin.com/show_bug.cgi?id=58778
* Bump versions for SR3
https://trello.com/c/EVze08ei
* Bump mono to include HttpClientHandler fix#44027https://trello.com/c/jYFXadH8/8-systemnethttp-close-request-stream-when-httpclienthandlerhttps://bugzilla.xamarin.com/show_bug.cgi?id=44027
We need the 'mono_profiler_startup_log' symbol when profiling is enabled, so
make sure to add the symbol to the correct list of symbols we need.
Previously we were passing `-u _mono_profiler_startup_log` to clang directly,
which is fine, but not complete, since it does not write the symbol to the
symbollist file (--symbollist=file), which means it wouldn't be preserved when
the MSBuild tasks strip the executable.
https://bugzilla.xamarin.com/show_bug.cgi?id=58778
Previously the assumption was that if an assembly not using dlsym references a
native symbol, it's not a required symbol. This is true as far as the native
linker goes: the native linker will see that the native symbol is referenced
by the AOT-compiled code, and it won't be removed.
However, we use also this exact logic to create the list of functions we ask
the native strip command to preserve, and in this case we need to include all
symbols needed in all assemblies that looks up native functions using dlsym.
https://bugzilla.xamarin.com/show_bug.cgi?id=57826
* [CoreNFC] Add CoreNFC Xcode 9 Beta 1 Bindings
CoreNFC is not exposed in iOS simulator, no framework/headers are found
makes sense since there is no NFC chip on it.
CoreNFC says it is available on tvOS but headers says just 3 enums
are so not enabling tvOS in this first beta.
* [mtouch] CoreNFC not available on sim, this makes mtouch aware of it
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
When gathering frameworks, gather into the product assembly's frameworks, not
the global frameworks.
This is necessary when building a non-linked dylib/framework in embeddor mode,
because we link the registrar code into the framework, and that code will
require linking with all the frameworks all the assemblies require.
- Before this mmp was not adding -framework, -weak_framework consistently on non-static registrar use cases
- GatherFrameworks was previously not ported from mtouch, and did not work as DeploymentTarget was unset in mmp
- Added verbose prints so users can determine why various framework linkages are added
- Fixed an issue where duplicate were being added due to HandleFramework shoving args by hand
- Tested with auto test and https://github.com/chamons/xm-version-regression-test manual test
Warn if mtouch loads an assembly from a different location than requested
(which might be because there are multiple assemblies with the same name).
Also rework the MT0023 check a bit by explicitly loading the root assembly
first, and then detecting if any loaded assemblies matches the root assembly.
This results in code that's a bit more obvious, and it also works correctly
with extensions (previously the entire MT0023 check was skipped for
extensions).
Create a custom AssemblyCollection class that contains a dictionary with
assembly identity (name) -> Assembly mapping.
This also means that we can detect if we end up loading multiple assemblies
with the same identity, and show an error in that case (even if that case
should never happen since we cache assemblies based on the identity, it's nice
to have code that ensures it).
Most projects building to bitcode (any kind of bitcode, this includes the
marker-only version as well), will fail to link when linking with third-party
libraries and incremental builds are enabled.
So automatically disable incremental builds when we detect this scenario.
This is only a workaround until we can make this scenario build correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Remove most static state and put it on an instance.
Remove most static state, and put it on an instance (of Application) instead.
Soon we'll build multiple apps (app extensions) in the same process, and we
need to make sure we're not inadvertedly (and incorrectly) sharing state
between apps, so remove as much static state as possible to avoid any
problems.
* [mtouch] Rename GetIsUsingClang -> IsUsingClang.
mtouch only uses Xamarin.Mac to read plists, so change to use
our purely managed plist reader in Xamarin.MacDev instead.
That makes us able to change mtouch to be a normal command-line
executable (and project).
Which makes it logical to not mkbundle mtouch anymore,
it executes just fine with the system mono (and there's
no code to protect anymore either).
And since mmp and mtouch share some files, do the same
for mmp.
Rolf Bjarne Kvinge
Sebastien Pouliot
Sebastien Pouliot
Alex Soto
Alex Soto
Timothy Risi
Chris Hamons