Heh, we have -ObjC to solve this for categories, but that's not the same thing. @jckarter, @gparker42, thoughts?

You can use -force_load to get load-everything semantics for a single archive, which is better than -all_load.

-ObjC might just work. The linker will pull in the ObjC category representing the extension, and that might be enough to pull in the rest.

Not all Swift extensions have corresponding categories, and the protocol conformance info probably isn't attached. I suppose we could start vending dummy categories…

If I recall correctly there is some symbol attribute that the compiler can add which tells the linker to pull in that definition unconditionally. Let me look around.

There definitely is, at some point I was actually trying to debug an issue with something like that, you can see when they're marked with that attribute using `nm -m`. Example:

% nm -m ./Library.o
...
00000000000002b8 (__DATA,__const) non-external [no dead strip] __TMfV7Library3Foo
...

I talked to the linker guys and there is not. Symbols can be marked no-dead-strip, but the lazy-loading semantics of static archives do not honor that. We may need to get linker enhancements if we need a fix for Swift there.

The usual solution is to avoid static archives. Instead, use ld -r to combine your .o files into one big .o file, then dead-strip that. That will remove some of the unused code that you get from static archive linking while also honoring no-dead-strip symbols.

@swift-ci create

Comment by Michael Bachand (JIRA)

We are experiencing this issue at Airbnb with Buck-generated Xcode projects that use Swift static libraries. We plan to use @objc (paired with the -ObjC "Other Linker Flag") to work around it.

Comment by Michael Bachand (JIRA)

Here is a repro in a Buck-generated project: airbnb/BuckSample#38

@belkadan @gparker42 any idea on how we can move forward to a fix for this one? I'd be willing to take a stab at some implementation for this if possible

soffes (JIRA User), Could you verify if the problem is fixed in the latest Xcode betas and if so move the JIRA to "Closed"?

Thanks!
Anna

Did something change in Swift that should have fixed this?

In Swift 5.1, per the Xcode release notes, this is now fixed for us. We use -ObjC though, so that might be it.

There was a linker side change to address this.

Ah interesting, I see this in the release notes "Static libraries are now always force-loaded in their entirety during linking, fixing runtime errors related to demangling failures. (47598583)"

On the surface this sounds pretty scary! Since we're intentionally not force loading all of our libraries, only the ones that experience this problem. But I can try to see if it fixed our case as well

The sample project attached to this issue actually still has the original problem with Xcode 11 beta 5

Setting GENERATE_MASTER_OBJECT_FILE on the Xcode target (as suggested in order to do the `ld -r` combination above) does fix this case.

The -ObjC in the original project is on the static libraries rather than the client of the static libraries (the app). If I fix that, and tell ModelsUI not to link with Models, it works in Xcode 11 (beta 6, but should be earlier ones too).

I do notice that there's not a dedicated build setting for -ObjC and people have to add it to "Other Linker Flags", so I'll go talk to some linker and Xcode folks about that. That'll be Apple-internal conversations only, though, sorry.

@belkadan to clarify, this new swift linking behavior is enabled by the -ObjC flag?

Ok after a bit more testing with this project it looks like -ObjC does enable this new behavior? I updated the sample project locally to make sure DogView wasn't a NSObject subclass since adding -ObjC actually fixed this example even in Xcode 10.3, but it looks like that does enable this new Swift loading behavior.