[Driver] Don't pass ELF shared objects to swift-autolink-extract

[bulbazord]

Prior to performing linking on ELF platforms (except the PS4) we extract
autolink information from the object files that will be used during linking.
The current implementation passes all the linker inputs that are marked as an
TY_Object to swift-autolink-extract. There are a two cases where this is
not necessary or problematic.

In the first case, we are looking at an ELF shared object. Although
harmless, this is wasted work. Specifically, the .swift1_autolink_entries
entry in the object files are marked as SHF_EXCLUDE, meaning they will not be
merged into the final product during linking.

In the second case, we are linking against a linker script that looks like an
ELF shared object (ends with .so). In the previous case, the autolink-extract
step will succeed even if it does unnecessary work. In this case, the
autolink-extract step will fail because it cannot recognize the linker script as
an object file. You will observe an error something like this:

<unknown>:0: error: error opening input file '/path/to/libLinkerScript.so'
(The file was not recognized as a valid object file

Although your linker will know what to do with it, autolink-extract will halt
before you get to that point.

[bulbazord]

@swift-ci please test

[bulbazord]

cc @compnerd @DougGregor @CodaFi

[CodaFi]

The logic is sound. I wonder if there’s a cleaner way to pull inputs from the job graph than this, but otherwise LGTM.

Perhaps @davidungar would know more about that point.

[bulbazord]

friendly ping!

[DougGregor]

Part of me thinks that the right fix involves splitting TY_Object into separate file types for single object files vs. archives vs. shared libraries, but that's a much bigger undertaking. I'm okay with this for now; we'll want to do the same for the new driver.