[lld/mac] For catalyst outputs, tolerate implicitly linking against mac-only tbd filesBefore this, clang empty.cc -target x86_64-apple-ios13.1-macabi \ -framework CoreServices -fuse-ld=lld
[lld/mac] For catalyst outputs, tolerate implicitly linking against mac-only tbd filesBefore this, clang empty.cc -target x86_64-apple-ios13.1-macabi \ -framework CoreServices -fuse-ld=lldwould error out with ld64.lld: error: path/to/MacOSX.sdk/System/Library/Frameworks/ CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/ Versions/A/CarbonCore.tbd( /System/Library/Frameworks/ CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/ Versions/A/CarbonCore) is incompatible with x86_64 (macCatalyst)Now it works, like with ld64.Differential Revision: https://reviews.llvm.org/D124336
show more ...
[lld-macho] Deduplicate CFStrings`__cfstring` is a special literal section, so instead of breaking it upat symbol boundaries, we break it up at fixed-width boundaries (sinceeach literal is the sa
[lld-macho] Deduplicate CFStrings`__cfstring` is a special literal section, so instead of breaking it upat symbol boundaries, we break it up at fixed-width boundaries (sinceeach literal is the same size). Symbols can only occur at one of thoseboundaries, so this is strictly more powerful than`.subsections_via_symbols`.With that in place, we then run the section through ICF.This change is about perf-neutral when linking chromium_framework.Reviewed By: #lld-macho, gkmDifferential Revision: https://reviews.llvm.org/D105045
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.sThe reexport-nested-libs test added in D97438 was a bit wonky.First, it was linking against libReexportSystem.tbd which targets th
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.sThe reexport-nested-libs test added in D97438 was a bit wonky.First, it was linking against libReexportSystem.tbd which targets theiOS simulator, and which in turn attempted to re-export the iOSsimulator's libSystem. However, due to the way `-syslibroot` works, itwas actually re-exporting the macOS libSystem.As a result, the test was not actually able to resolve the symbols inthe desired libSystem. I'm guessing that @oontvoo was confused by thisand therefore included those symbols in libReexportSystem.tbd itself.But this means that the test wasn't actually testing the resolution ofre-exported symbols (though it did at least verify that the re-exportedlibraries could be located).After some consideration, I figured that stub-link.s could be extendedto cover what reexport-nested-libs.s was attempting to do. The testtargets macOS, so we only have one `-syslibroot` and no chance ofconfusion.Reviewed By: #lld-macho, oontvooDifferential Revision: https://reviews.llvm.org/D97866
[lld-macho] Generate ObjC symbols from .tbd filesI followed similar logic in TapiFile.cpp.Reviewed By: #lld-macho, smeenaiDifferential Revision: https://reviews.llvm.org/D85255
[lld-macho] Add .tbd support for frameworksRequired for e.g. linking iOS apps since they don't have a platform-nativeSDKReviewed By: #lld-macho, compnerd, smeenaiDifferential Revision: https:/
[lld-macho] Add .tbd support for frameworksRequired for e.g. linking iOS apps since they don't have a platform-nativeSDKReviewed By: #lld-macho, compnerd, smeenaiDifferential Revision: https://reviews.llvm.org/D85153