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

174 строки
11 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)
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)
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)
DEV_TV_I:= $(COMMON_I)
Add build system.
2016-04-21 11:59:27 +03:00
define NativeCompilationTemplate
## ios 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/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
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR86_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/usr/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] 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
$$(call Q_2,LD, [iphonesimulator]) $(SIMULATOR_CC) $(SIMULATOR64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IOSSIMULATOR_SDK)/usr/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
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
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/usr/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
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE7S_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/usr/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
$$(call Q_2,LD, [iphoneos]) $(DEVICE_CC) $(DEVICE64_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_IPHONEOS_SDK)/usr/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
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
$$(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
$$(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
$$(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
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHSIMULATOR_SDK)/usr/lib -fapplication-extension
.libs/watchsimulator/%$(1).x86.framework: | .libs/watchsimulator
$$(call Q_2,LD, [watchsimulator]) $(SIMULATOR_CC) $(SIMULATORWATCH_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
Switch the mono device/simulator/cross compiler builds to the mono SDK makefile. (#3640) * Switch the mono device/simulator/cross compiler builds to the mono SDK makefile. * Build these by recursing into external/mono/sdks/builds and calling the targets there. * Add a few extra rules to build dependencies like llvm and mono's configure to avoid these being build in parallel by the SDK makefile. * Copy config.h/eglib-config.h into builds/install so the build in runtime/ doesn't have to add the builddirs to its includes. * [builds] Fix install-llvm32 target, make command quiet. * [builds] Link the libraries in runtime/ against the installed libmono, so there is no need to run install_name_tool on them. * [builds] Fix up the rpath correctly for libmono-profiler-log.dylib. * [builds] Update to the new ios sdk targets (-release suffix). * Bump mono. * Bump mono. * [[builds] Update to the new ios sdk targets (-release suffix).
2018-03-23 04:25:00 +03:00
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/usr/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
$$(call Q_2,LD, [watchos]) $(DEVICE_CC) $(DEVICEWATCH64_32_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_WATCHOS_SDK)/usr/lib -fapplication-extension
.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] 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
$$(call Q_2,LD, [tvsimulator]) $(SIMULATOR_CC) $(SIMULATORTV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_TVSIMULATOR_SDK)/usr/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
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
Switch the mono device/simulator/cross compiler builds to the mono SDK makefile. (#3640) * Switch the mono device/simulator/cross compiler builds to the mono SDK makefile. * Build these by recursing into external/mono/sdks/builds and calling the targets there. * Add a few extra rules to build dependencies like llvm and mono's configure to avoid these being build in parallel by the SDK makefile. * Copy config.h/eglib-config.h into builds/install so the build in runtime/ doesn't have to add the builddirs to its includes. * [builds] Fix install-llvm32 target, make command quiet. * [builds] Link the libraries in runtime/ against the installed libmono, so there is no need to run install_name_tool on them. * [builds] Fix up the rpath correctly for libmono-profiler-log.dylib. * [builds] Update to the new ios sdk targets (-release suffix). * Bump mono. * Bump mono. * [[builds] Update to the new ios sdk targets (-release suffix).
2018-03-23 04:25:00 +03:00
$$(call Q_2,LD, [tvos]) $(DEVICE_CC) $(DEVICETV_CFLAGS) $$(EXTRA_FLAGS) -dynamiclib -o $$@ $$^ -L$(IOS_DESTDIR)$(XAMARIN_TVOS_SDK)/usr/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
Add build system.
2016-04-21 11:59:27 +03:00
endef
$(eval $(call NativeCompilationTemplate,,-O2))
$(eval $(call NativeCompilationTemplate,-debug,-DDEBUG))
[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 .libs/iphonesimulator .libs/watchos .libs/watchsimulator .libs/tvos .libs/tvsimulator .libs/iosmac:
Add build system.
2016-04-21 11:59:27 +03:00
$(Q) mkdir -p $@