Provide an API to understand linker arguments and the linked images

[abdulowork]

Description

This issue is a follow-up request to the feature request from issue #9511. When we import the 3rd party API’s into Kotlin, we must eventually materialize the machine code for the consumed APIs at the linkage site.

The Kotlin/Native backend of the Kotlin compiler can produce linked images (dylibs and executables) by calling ld, and currently, to understand what we need to pass to ld, we:

• Declare a fake dynamic target:

// Package.swift
  products: [.library(name: “fakeLibrary”, type: .dynamic, targets: [“fakeObjcTarget”])],
  …
  targets: [.target(name: “fakeObjctarget”, dependencies: [/* all of the dependencies we want to import */])]

• Run xcodebuild on this package with an LD override and parse linker arguments like
  • -F and -L search paths
  • -filelist, -framework, -l and similar linker arguments
  • Paths to .a and .dylib files from unwrapped .binaryTarget dependencies
• Forward all of those to the ld call

With linker arguments, we are also particularly interested in the paths to dynamic libraries. If the image we produce depends on another dynamic library, we need these to run tests, which we emit as an executable image. So right now we just pass all the -F and -L arguments as DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH, respectively.

Another complication for us when working with the linker is that SwiftPM can alter the linked image graph depending on the arrangement of the dynamic libraries in the final build. For example, when 2 dynamic products consume a product with type: .none, such a product will be promoted to a dynamic library (I assume to avoid unexpected machine code duplication). The challenge for us is that when we integrate into an Xcode project and produce a dynamic library rather than a static archive, we want to link correctly without pulling in machine code from libraries that will be promoted in the final application build. Sorry, if that’s a bit difficult to imagine, please let me know if an example would be helpful!

Similar to the concerns in #9511, our current mechanism for understanding the linker may prove unreliable in the future. SwiftPM and/or Swift Build could communicate with a foreign build system, for which linker arguments are required, and what arrangement of dynamic libraries will be produced.

Such an API will also be helpful for Swift Java interop if this interop supports a mode for foreign build systems in the future.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Swift Package Manager version/commit hash

No response

Swift & OS version (output of swift --version && uname -a)

No response