[PATCH] D146776: [llvm] Preliminary fat-lto-objects support

[Arthur Eubanks via Phabricator via llvm-commits]

aeubanks added a comment.

In D146776#4435430 <https://reviews.llvm.org/D146776#4435430>, @paulkirth wrote:

> In D146776#4430608 <https://reviews.llvm.org/D146776#4430608>, @MaskRay wrote:
>
>> Started looking...
>>
>> `-DBUILD_SHARED_LIBS=on` uses `-Wl,-z,defs` and can detect some library layering (https://llvm.org/docs/CodingStandards.html#library-layering https://maskray.me/blog/2021-06-13-dependency-related-linker-options)  problems. `ninja LLVMBitWriter` doesn't build due to missing dependencies.
>>
>> One issue can be addressed with the following change but the dependency may be a bit weird.
>>
>>   diff --git i/llvm/lib/Bitcode/Writer/CMakeLists.txt w/llvm/lib/Bitcode/Writer/CMakeLists.txt
>>   index 2b17aa912016..51849d2d0fc0 100644
>>   --- i/llvm/lib/Bitcode/Writer/CMakeLists.txt
>>   +++ w/llvm/lib/Bitcode/Writer/CMakeLists.txt
>>   @@ -17,2 +17,4 @@ add_llvm_component_library(LLVMBitWriter
>>      TargetParser
>>   +  TransformUtils
>>      )
>>
>> The other issue (`error: undefined symbol: llvm::ThinLTOBitcodeWriterPass::run`) is more tricky: LLVMipo (`llvm/lib/Transforms/IPO/CMakeLists.txt`) depends on LLVMBitWriter, so LLVMBitWriter cannot depend on LLVMipo.
>
> What if we move the pass into transforms? Yes, its fairly correlated to bitcode writing, but the pass is really just creating a new section using existing utilities, which could just be considered a transform. There's also an argument that this pass should just live wherever the ThinLTOBitcodeWritterPass does. I //think// that should fix both the issues you've mentioned here.
>
> Do you think that would be a better solution?

yes living alongside `ThinLTOBitcodeWritterPass` makes sense


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146776/new/

https://reviews.llvm.org/D146776