xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/mk/rules.mk

306 строки
19 KiB
Makefile
Исходник Обычный вид История

Add build system.
2016-04-21 11:59:27 +03:00
# helpful rules to compile things for the various architectures
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
COMMON_I:= -I.
SIM32_I := $(COMMON_I)
SIM64_I := $(COMMON_I)
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
SIM_ARM64_I := $(COMMON_I)
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
DEV7_I := $(COMMON_I)
DEV7s_I := $(COMMON_I)
DEV64_I := $(COMMON_I)
[runtime] integrate mono 2017-10 (#2905) * Update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. * [builds] Pass --with-cross-offsets= to crosstv's configure. * Bump mono to 2017-08. * Bump mono to 2017-08. * Force disable 'futimens' and 'utimensat' so that we build with Xcode 9. This is also needed to build with Xcode 8.3 on High Sierra. * Remove old AppleTls implementation. * Bump mono. * Bump mono to 2017-08. * Bump mono to 2017-08 * Reenable link-keep-resources-2 test - This reverts commit 76b759ef22c06cda3ba30aba1ac0d45634e4fbf4. - 2017-08 has linker fix * Bump mono to 2017-10 * Revert "Bump mono to 2017-10" This reverts commit bb7832724e18f8578449e46426382a537f3f4823. * Bump system mono to 2017-10 * Bump embedded mono to 2017-10 * [runtime] reflect eglib move https://github.com/mono/mono/commit/9be68f8952ea0e1aad582bfe2f47bad71aee2cc7 * bump mono * [btouch] remove Security.Tls usage from test * [mtouch tests] update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. see https://github.com/mono/mono/commit/ea4e4a9ef6fc42570a23026adbe826cf7248290e fixes: ``` 1) Failed : Xamarin.MTouch.Profiling(tvOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 2) Failed : Xamarin.MTouch.Profiling(watchOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_xamarin_get_block_descriptor", "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 ``` * [mmptest] update log profiler options. https://github.com/mono/mono/commit/826558a4af624bc0acaea98ec39784e65d278091 deprecated the dash prefix for the mlpd path. `noallocs` or `nocalls` are not needed, neither of them are default anymore. * [mmptest] fix link-keep-resources-2 test to cope with more corlib resources. another corlib resource (mscorlib.xml) was added: https://github.com/mono/mono/commit/11e95169e787#diff-2d1c64decd91d9a6e8842ab0f0e9438d * Revert "[mmptest] fix link-keep-resources-2 test to cope with more corlib resources." This reverts commit 350eb3c174288bbffcc3b7acb15cadb913af25b7. * [XHarness] Add the Mono.Data.Tds tests. * Address comments from rolf in the review. * [mmp regresssion tests] bump mono linker, so mscorlib.xml gets stripped the test was failing in that way: > Executing link-keep-resources-2... > [FAIL] i18n 4/2 data files present: charinfo.nlp, collation.core.bin, collation.tailoring.bin, mscorlib.xml also update the output, because it's actually expected at least three elements. fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59277 * bump mono fixes crash in tvOS: https://github.com/mono/mono/pull/5812 * bump mono for updated BCL tests see https://github.com/mono/mono/pull/5820 * [mono] set 2017-10 branch in .gitmodules * [macos] Fix guiunit error on clean builds by depending on correct copy (#2912) * [macos] Fix guiunit error on clean builds by depending on correct copy - From a clean build making a BCL test would error due to the non-mobile guiunit not being built - This was because the Makefile-mac.inc target was incorrect - This was because xharness assumed that non variation based targets were always Modern - However, BCL tests are Full, not Modern * Code review change * Swap to var to reduce diff * Revert changes in the paths for GuiUnit. * [XHarness] Add the System.IO.Compression bcl tests. (#2918) * [XHarness] Add the System.IO.Compression bcl tests. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. (#2924) * [XHarness] Add the System.IO.Compression bcl tests. * Ensure that resources are correctly copied in the bundles. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. * As per review, make the Mac test app name match the tests that are ran. * [XHarness] Add Mono.CSharp tests on ios. (#2927) * [XHarness] Add Mono.CSharp tests on ios. * Bump mono to bring changes in the mono.csharp tests. * [xtro-sharpie] fix TypeDefinition access due to Cecil change * Bump mono * bump mono fixes - https://bugzilla.xamarin.com/show_bug.cgi?id=60480 - https://bugzilla.xamarin.com/show_bug.cgi?id=60482 * bump mono more fixes around conflicting paths when tests are run in parallel. * Bump for mono/mono@2017-10
2017-11-14 23:30:08 +03:00
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
SIMW_I := $(COMMON_I)
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
SIMW64_I := $(COMMON_I)
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
DEVW_I := $(COMMON_I)
[build/runtime] Add build rules for arm64_32
2019-01-23 23:01:43 +03:00
DEVW64_32_I := $(COMMON_I)
[runtime] integrate mono 2017-10 (#2905) * Update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. * [builds] Pass --with-cross-offsets= to crosstv's configure. * Bump mono to 2017-08. * Bump mono to 2017-08. * Force disable 'futimens' and 'utimensat' so that we build with Xcode 9. This is also needed to build with Xcode 8.3 on High Sierra. * Remove old AppleTls implementation. * Bump mono. * Bump mono to 2017-08. * Bump mono to 2017-08 * Reenable link-keep-resources-2 test - This reverts commit 76b759ef22c06cda3ba30aba1ac0d45634e4fbf4. - 2017-08 has linker fix * Bump mono to 2017-10 * Revert "Bump mono to 2017-10" This reverts commit bb7832724e18f8578449e46426382a537f3f4823. * Bump system mono to 2017-10 * Bump embedded mono to 2017-10 * [runtime] reflect eglib move https://github.com/mono/mono/commit/9be68f8952ea0e1aad582bfe2f47bad71aee2cc7 * bump mono * [btouch] remove Security.Tls usage from test * [mtouch tests] update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now. see https://github.com/mono/mono/commit/ea4e4a9ef6fc42570a23026adbe826cf7248290e fixes: ``` 1) Failed : Xamarin.MTouch.Profiling(tvOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 2) Failed : Xamarin.MTouch.Profiling(watchOS) _mono_profiler_startup_log Expected: collection containing "_mono_profiler_startup_log" But was: < "_xamarin_get_block_descriptor", "_mono_profiler_init_log" > at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0 ``` * [mmptest] update log profiler options. https://github.com/mono/mono/commit/826558a4af624bc0acaea98ec39784e65d278091 deprecated the dash prefix for the mlpd path. `noallocs` or `nocalls` are not needed, neither of them are default anymore. * [mmptest] fix link-keep-resources-2 test to cope with more corlib resources. another corlib resource (mscorlib.xml) was added: https://github.com/mono/mono/commit/11e95169e787#diff-2d1c64decd91d9a6e8842ab0f0e9438d * Revert "[mmptest] fix link-keep-resources-2 test to cope with more corlib resources." This reverts commit 350eb3c174288bbffcc3b7acb15cadb913af25b7. * [XHarness] Add the Mono.Data.Tds tests. * Address comments from rolf in the review. * [mmp regresssion tests] bump mono linker, so mscorlib.xml gets stripped the test was failing in that way: > Executing link-keep-resources-2... > [FAIL] i18n 4/2 data files present: charinfo.nlp, collation.core.bin, collation.tailoring.bin, mscorlib.xml also update the output, because it's actually expected at least three elements. fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59277 * bump mono fixes crash in tvOS: https://github.com/mono/mono/pull/5812 * bump mono for updated BCL tests see https://github.com/mono/mono/pull/5820 * [mono] set 2017-10 branch in .gitmodules * [macos] Fix guiunit error on clean builds by depending on correct copy (#2912) * [macos] Fix guiunit error on clean builds by depending on correct copy - From a clean build making a BCL test would error due to the non-mobile guiunit not being built - This was because the Makefile-mac.inc target was incorrect - This was because xharness assumed that non variation based targets were always Modern - However, BCL tests are Full, not Modern * Code review change * Swap to var to reduce diff * Revert changes in the paths for GuiUnit. * [XHarness] Add the System.IO.Compression bcl tests. (#2918) * [XHarness] Add the System.IO.Compression bcl tests. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. (#2924) * [XHarness] Add the System.IO.Compression bcl tests. * Ensure that resources are correctly copied in the bundles. * [XHarness] Add bcl tests for System.IO.Compression.FileSystem. * As per review, make the Mac test app name match the tests that are ran. * [XHarness] Add Mono.CSharp tests on ios. (#2927) * [XHarness] Add Mono.CSharp tests on ios. * Bump mono to bring changes in the mono.csharp tests. * [xtro-sharpie] fix TypeDefinition access due to Cecil change * Bump mono * bump mono fixes - https://bugzilla.xamarin.com/show_bug.cgi?id=60480 - https://bugzilla.xamarin.com/show_bug.cgi?id=60482 * bump mono more fixes around conflicting paths when tests are run in parallel. * Bump for mono/mono@2017-10
2017-11-14 23:30:08 +03:00
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
SIM_TV_I:= $(COMMON_I)
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
SIM_ARM64_TV_I := $(COMMON_I)
Use the zlib-helper.o library built by mono, instead of building our own. (#5021) This also makes it possible to simplify/remove some of our build logic.
2018-10-23 02:52:45 +03:00
DEV_TV_I:= $(COMMON_I)
Add build system.
2016-04-21 11:59:27 +03:00
define NativeCompilationTemplate
## ios simulator
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
### X86
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,OBJC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,CC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86.o: %.s $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,ASM, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_DEFINES) $(SIM32_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86.dylib: | .libs/iphonesimulator
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86.framework: | .libs/iphonesimulator
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/Frameworks -fapplication-extension
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
### X64
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,OBJC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM64_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,CC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_DEFINES) $(SIM64_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,ASM, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $(SIM64_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86_64.dylib: | .libs/iphonesimulator
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphonesimulator/%$(1).x86_64.framework: | .libs/iphonesimulator
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/Frameworks -fapplication-extension
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
### ARM64
.libs/iphonesimulator/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,OBJC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR_ARM64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM_ARM64_I) -g $(2) -c $$< -o $$@
.libs/iphonesimulator/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,CC, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR_ARM64_CFLAGS) $$(EXTRA_DEFINES) $(SIM_ARM64_I) -g $(2) -c $$< -o $$@
.libs/iphonesimulator/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/iphonesimulator
$$(call Q_2,ASM, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR_ARM64_CFLAGS) $(SIM64_I) -g $(2) -c $$< -o $$@
.libs/iphonesimulator/%$(1).arm64.dylib: | .libs/iphonesimulator
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/lib -fapplication-extension
.libs/iphonesimulator/%$(1).arm64.framework: | .libs/iphonesimulator
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## ios device
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,OBJC, [iphoneos]) $(DEVICE_CC) $(DEVICE7_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV7_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,CC, [iphoneos]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_DEFINES) $(DEV7_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7.dylib: | .libs/iphoneos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7.framework: | .libs/iphoneos
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7s.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,OBJC, [iphoneos]) $(DEVICE_CC) $(DEVICE7S_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV7s_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7s.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,CC, [iphoneos]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_DEFINES) $(DEV7s_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7s.dylib: | .libs/iphoneos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).armv7s.framework: | .libs/iphoneos
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,OBJC, [iphoneos]) $(DEVICE_CC) $(DEVICE64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV64_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,CC, [iphoneos]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_DEFINES) $(DEV64_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/iphoneos
$$(call Q_2,ASM, [iphoneos]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_DEFINES) $(DEV64_I) -g $(2) -c $$< -o $$@
[runtime] Implement support for an arm64 dynamic registrar. (#6005) This is required in order to execute downloaded assemblies (or any other assembly not known at compile time) on device.
2019-05-07 08:35:39 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).arm64.dylib: | .libs/iphoneos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/iphoneos/%$(1).arm64.framework: | .libs/iphoneos
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/Frameworks -fapplication-extension -miphoneos-version-min=8.0
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
## maccatalyst (ios on macOS / Catalyst)
.libs/maccatalyst/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$$(call Q_2,OBJC, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_X86_64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(COMMON_I) -g $(2) -c $$< -o $$@
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
.libs/maccatalyst/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$$(call Q_2,CC, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_X86_64_CFLAGS) $$(EXTRA_DEFINES) $(COMMON_I) -g $(2) -c $$< -o $$@
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
.libs/maccatalyst/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$$(call Q_2,ASM, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_X86_64_CFLAGS) $(COMMON_I) -g $(2) -c $$< -o $$@
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
.libs/maccatalyst/%$(1).x86_64.dylib: | .libs/maccatalyst
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$$(call Q_2,LD, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_X86_64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_MACCATALYST_SDK)/lib -fapplication-extension
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
.libs/maccatalyst/%$(1).x86_64.framework: | .libs/maccatalyst
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$$(call Q_2,LD, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_X86_64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_MACCATALYST_SDK)/Frameworks -fapplication-extension
.libs/maccatalyst/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
$$(call Q_2,OBJC, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_ARM64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/maccatalyst/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
$$(call Q_2,CC, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_ARM64_CFLAGS) $$(EXTRA_DEFINES) $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/maccatalyst/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/maccatalyst
$$(call Q_2,ASM, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_ARM64_CFLAGS) $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/maccatalyst/%$(1).arm64.dylib: | .libs/maccatalyst
$$(call Q_2,LD, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_MACCATALYST_SDK)/lib -fapplication-extension
.libs/maccatalyst/%$(1).arm64.framework: | .libs/maccatalyst
$$(call Q_2,LD, [maccatalyst]) $(XCODE_CC) $(MACCATALYST_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_MACCATALYST_SDK)/Frameworks -fapplication-extension
[runtime] Build our runtime for Catalyst.
2020-11-17 11:12:51 +03:00
Add build system.
2016-04-21 11:59:27 +03:00
## watch simulator
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/watchsimulator/%$(1).x86.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
$$(call Q_2,OBJC, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/watchsimulator/%$(1).x86.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
$$(call Q_2,CC, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/watchsimulator/%$(1).x86.o: %.s $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
$$(call Q_2,ASM, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_DEFINES) $(SIMW_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/watchsimulator/%$(1).x86.dylib: | .libs/watchsimulator
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/lib -fapplication-extension
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/watchsimulator/%$(1).x86.framework: | .libs/watchsimulator
[main][watchOS] Add x86_64 simulator support (#10059) * [watchOS] Add x86_64 simulator support * Build runtime/registrar x86_64 slices * Produce a 64 bit version of Xamarin.WatchOS.dll * Allow building x86_64 for watch simulators in mtouch * Let xharness know about x86_64 * [tests] Add x86_64 arch to test-libraries * Make dotnet package aware of x64 * [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator. * [xharness] Re-enable some watchOS tests. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2020-11-20 17:27:46 +03:00
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/Frameworks -fapplication-extension
.libs/watchsimulator/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
$$(call Q_2,OBJC, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIMW64_I) -g $(2) -c $$< -o $$@
.libs/watchsimulator/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
$$(call Q_2,CC, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH64_CFLAGS) $$(EXTRA_DEFINES) $(SIMW64_I) -g $(2) -c $$< -o $$@
.libs/watchsimulator/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/watchsimulator
$$(call Q_2,ASM, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH64_CFLAGS) $$(EXTRA_DEFINES) $(SIMW64_I) -g $(2) -c $$< -o $$@
.libs/watchsimulator/%$(1).x86_64.dylib: | .libs/watchsimulator
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/lib -fapplication-extension
.libs/watchsimulator/%$(1).x86_64.framework: | .libs/watchsimulator
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## watch device
.libs/watchos/%$(1).armv7k.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,OBJC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEVW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).armv7k.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,CC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_DEFINES) $(DEVW_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).armv7k.dylib: | .libs/watchos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/watchos/%$(1).armv7k.framework: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/Frameworks -fapplication-extension
[build/runtime] Add build rules for arm64_32
2019-01-23 23:01:43 +03:00
.libs/watchos/%$(1).arm64_32.o: %.m $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,OBJC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH64_32_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEVW64_32_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).arm64_32.o: %.c $(EXTRA_DEPENDENCIES) | .libs/watchos
$$(call Q_2,CC, [watchos]) $(DEVICE_CC) $(DEVICEWATCH64_32_CFLAGS) $$(EXTRA_DEFINES) $(DEVW64_32_I) -g $(2) -c $$< -o $$@
.libs/watchos/%$(1).arm64_32.dylib: | .libs/watchos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH64_32_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/lib -fapplication-extension
[build/runtime] Add build rules for arm64_32
2019-01-23 23:01:43 +03:00
.libs/watchos/%$(1).arm64_32.framework: | .libs/watchos
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH64_32_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## tv simulator
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
### X64
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/tvsimulator/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,OBJC, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/tvsimulator/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,CC, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/tvsimulator/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,ASM, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_DEFINES) $(SIM_TV_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/tvsimulator/%$(1).x86_64.dylib: | .libs/tvsimulator
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Split the build differently: build libraries for simulator and device separately. (#7143) This has a couple of advantages: * It makes it easier to add a catalyst version of these libraries (because it becomes cumbersome to build for catalyst when the build rules assumes we're building for both simulator and device). * It makes it easier to create an xcframework of our libraries, because the contents in an xcframework is split like this.
2019-10-03 17:38:44 +03:00
.libs/tvsimulator/%$(1).x86_64.framework: | .libs/tvsimulator
$$(call Q_2,LD, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/Frameworks -fapplication-extension
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
[runtime] Build for ARM64/simulators.
2021-11-23 02:41:25 +03:00
### ARM64
.libs/tvsimulator/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,OBJC, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_ARM64_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(SIM_ARM64_TV_I) -g $(2) -c $$< -o $$@
.libs/tvsimulator/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,CC, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_ARM64_CFLAGS) $$(EXTRA_DEFINES) $(SIM_ARM64_TV_I) -g $(2) -c $$< -o $$@
.libs/tvsimulator/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/tvsimulator
$$(call Q_2,ASM, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_ARM64_CFLAGS) $$(EXTRA_DEFINES) $(SIM_ARM64_TV_I) -g $(2) -c $$< -o $$@
.libs/tvsimulator/%$(1).arm64.dylib: | .libs/tvsimulator
$$(call Q_2,LD, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/lib -fapplication-extension
.libs/tvsimulator/%$(1).arm64.framework: | .libs/tvsimulator
$$(call Q_2,LD, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_ARM64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
## tv device
.libs/tvos/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,OBJC, [tvos]) $(DEVICE_CC) $(DEVICETV_OBJC_CFLAGS) $$(EXTRA_DEFINES) $(DEV_TV_I) -g $(2) -c $$< -o $$@
.libs/tvos/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,CC, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_DEFINES) $(DEV_TV_I) -g $(2) -c $$< -o $$@
[runtime] Implement support for an arm64 dynamic registrar. (#6005) This is required in order to execute downloaded assemblies (or any other assembly not known at compile time) on device.
2019-05-07 08:35:39 +03:00
.libs/tvos/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/tvos
$$(call Q_2,ASM, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_DEFINES) $(DEV_TV_I) -g $(2) -c $$< -o $$@
Add build system.
2016-04-21 11:59:27 +03:00
.libs/tvos/%$(1).arm64.dylib: | .libs/tvos
[mmp/mtouch] Share more code. (#8394) * Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and mtouch, by putting mono's static and dynamic libraries in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk to match how Xamarin.iOS does it. * Don't use 'usr' as an intermediate directory. This removes another special case. * Share many of the functions and properties that return specific directories, and document (as comments) what each function/property is supposed to return.
2020-04-16 15:19:45 +03:00
$$(call Q_2,LD, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_TVOS_SDK)/lib -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
Fix how we build frameworks. Fixes #53813. (#1952) Previously we copied any equivalent .dylib and ran install_name_tool on the library to change the library id to make it a framework. Unfortunately this does not work when the library contains bitcode, because bitcode embeds linker flags (-install_name for instance), and install_name_tool does not change those linker flags. This means that we need to create frameworks by linking with the proper arguments, since it's much more difficult to fixup the embedded bitcode linker flags as well. So change how be build Mono.framework, Xamarin.framework, and any frameworks built from assemblies to: * Always link instead of fixup a dylib. For Mono.framework this means extracting all the object files from libmonosgen-2.0.a and linking those, for Xamarin.framework this means linking the object files we've already built. * Make sure the library is correctly named when linked (once again: bitcode contains embedded linker flags, so renaming the executable later breaks stuff as well). I've also extracted the logic that creates Mono.framework from libmonosgen-2.0.a to a separate shell script, to deduplicate this logic. This required a minor change in the mono builds: we need the Mono.framework when building the `all` target, so make sure that happens. https://bugzilla.xamarin.com/show_bug.cgi?id=53813
2017-04-03 12:52:29 +03:00
.libs/tvos/%$(1).arm64.framework: | .libs/tvos
$$(call Q_2,LD, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -F$(IOS_DESTDIR)$(XAMARIN_TVOS_SDK)/Frameworks -fapplication-extension
[runtime] Build a .NET-specific libxamarin-dotnet[-debug].[a|dylib]. (#10723) This also means linking with the runtime packs from .NET instead of the mono archive (thus we have one less reliance on the mono archive). We're also using the Xamarin.iOS code for our macOS launch sequence now, since (at least at first) we're only going to support self-contained .NET macOS apps (so no need to support a system-installed runtime, which simplifies things a bit).
2021-02-26 16:42:30 +03:00
## macOS
.libs/mac/%$(1).x86_64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,OBJC, [mac]) $(MAC_CC) $(MAC_OBJC_CFLAGS) $$(EXTRA_DEFINES) -arch x86_64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).x86_64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,CC, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_DEFINES) -arch x86_64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).x86_64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,ASM, [mac]) $(MAC_CC) $(MAC_CFLAGS) -arch x86_64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).x86_64.dylib: | .libs/mac
$$(call Q_2,LD, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_FLAGS) -arch x86_64 -dynamiclib -o $$@ $$^ -L$(MAC_DESTDIR)$(XAMARIN_MACOS_SDK)/lib -fapplication-extension
.libs/mac/%$(1).x86_64.framework: | .libs/mac
$$(call Q_2,LD, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_FLAGS) -arch x86_64 -dynamiclib -o $$@ $$^ -F$(MAC_DESTDIR)$(XAMARIN_MACOS_SDK)/Frameworks -fapplication-extension
[dotnet] Build macOS/.NET for ARM64 as well. (#10959) Partial fix for #10959.
2021-03-25 09:26:48 +03:00
.libs/mac/%$(1).arm64.o: %.m $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,OBJC, [mac]) $(MAC_CC) $(MAC_OBJC_CFLAGS) $$(EXTRA_DEFINES) -arch arm64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).arm64.o: %.c $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,CC, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_DEFINES) -arch arm64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).arm64.o: %.s $(EXTRA_DEPENDENCIES) | .libs/mac
$$(call Q_2,ASM, [mac]) $(MAC_CC) $(MAC_CFLAGS) -arch arm64 $(COMMON_I) -g $(2) -c $$< -o $$@
.libs/mac/%$(1).arm64.dylib: | .libs/mac
$$(call Q_2,LD, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_FLAGS) -arch arm64 -dynamiclib -o $$@ $$^ -L$(MAC_DESTDIR)$(XAMARIN_MACOS_SDK)/lib -fapplication-extension
.libs/mac/%$(1).arm64.framework: | .libs/mac
$$(call Q_2,LD, [mac]) $(MAC_CC) $(MAC_CFLAGS) $$(EXTRA_FLAGS) -arch arm64 -dynamiclib -o $$@ $$^ -F$(MAC_DESTDIR)$(XAMARIN_MACOS_SDK)/Frameworks -fapplication-extension
Add build system.
2016-04-21 11:59:27 +03:00
endef
$(eval $(call NativeCompilationTemplate,,-O2))
$(eval $(call NativeCompilationTemplate,-debug,-DDEBUG))
[runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. (#10739) * [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET. * [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst. This also fixes a build error: error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan. * Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst. * [tests] Update to not run the StartWWAN test on Mac Catalyst. * Update conditional logic. * Fix build with newer make versions.
2021-03-03 09:48:07 +03:00
$(eval $(call NativeCompilationTemplate,-dotnet,-O2 -DDOTNET))
$(eval $(call NativeCompilationTemplate,-dotnet-debug,-DDEBUG -DDOTNET))
[runtime] Build a new version of libxamarin specifically for CoreCLR. (#10798) We're currently only building for macOS, but we'll eventually build for Mac Catalyst as well.
2021-03-08 09:57:55 +03:00
$(eval $(call NativeCompilationTemplate,-dotnet-coreclr,-O2 -DCORECLR_RUNTIME -DDOTNET))
$(eval $(call NativeCompilationTemplate,-dotnet-coreclr-debug,-DDEBUG -DCORECLR_RUNTIME -DDOTNET))
Add build system.
2016-04-21 11:59:27 +03:00
[runtime] Build a .NET-specific libxamarin-dotnet[-debug].[a|dylib]. (#10723) This also means linking with the runtime packs from .NET instead of the mono archive (thus we have one less reliance on the mono archive). We're also using the Xamarin.iOS code for our macOS launch sequence now, since (at least at first) we're only going to support self-contained .NET macOS apps (so no need to support a system-installed runtime, which simplifies things a bit).
2021-02-26 16:42:30 +03:00
.libs/iphoneos .libs/iphonesimulator .libs/watchos .libs/watchsimulator .libs/tvos .libs/tvsimulator .libs/maccatalyst .libs/mac:
Add build system.
2016-04-21 11:59:27 +03:00
$(Q) mkdir -p $@
Create a general rule to create makefile fragments for project files. (#8320) The generator project file still needs some custom logic, because we can't put the generated makefile fragment next to the csproj (that would break the API/generator diff).
2020-04-08 17:59:17 +03:00
%.csproj.inc: %.csproj $(TOP)/Make.config $(TOP)/mk/mono.mk $(TOP)/tools/common/create-makefile-fragment.sh
$(Q) $(TOP)/tools/common/create-makefile-fragment.sh $(abspath $<) $(abspath $@)