Fix how we build frameworks. Fixes #53813. - #1952
Merged
Merged
Conversation
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
Contributor
|
Build failure |
spouliot
approved these changes
Mar 31, 2017
Contributor
|
Jenkins could not clone some repo |
Contributor
|
build |
Contributor
|
Build success |
rolfbjarne
added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 11, 2017
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
spouliot
pushed a commit
that referenced
this pull request
Apr 11, 2017
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
alltarget, so make sure that happens.https://bugzilla.xamarin.com/show_bug.cgi?id=53813