Comment by Shai Mishali (JIRA)

P.S. the `NOT_IN_PLAYGROUND` flag is unrelated, it's something internal:
https://github.com/ReactiveX/RxSwift/blob/master/Rx.playground/Sources/SupportCode.swift#L36

I think this is just "you can't import static libraries into the JIT because dlopen doesn't know how to load them". If you use swiftc instead of swift it'll probably work…and moreover it won't actually run the playground, which depending on the contents of the playground might be a good thing. (Imagine a playground that shows how to modify on-disk content!)

Comment by Shai Mishali (JIRA)

I'm not knowledgable enough with JIT or swiftc, but this isn't actually using Playground. What the script does is just merge all Swift files into a single Swift file and compile it as a regular Swift script, not a Playground. The segmentation fault is clearly not the expected outcome here 🙂

Even after disabling this failing script, we're failing with what seems to be a known issue in Swift 5 (47598583):

> Linking against a static Swift library might create a binary with missing type metadata because the object files that define the metadata inside the static archive are mistakenly considered unused.
>
> This can manifest as a Swift runtime error with a message such as: “failed to demangle superclass of MyClass from mangled name ‘<mangled name>’”.
>
> Workaround: If you can rebuild the static library, try building it with whole module optimization enabled. Otherwise, add -all_load to the linker flags in the client binary to ensure all object files are linked into it.

It's not compiling the file; it's interpreting it. That's the difference between swift and swiftc.

Comment by Shai Mishali (JIRA)

And that's something not possible with a Static Library ? We've never had an issue with Dynamic Libraries here.
In any way, I imagine there should be an actual error to work with here, in an optimal world? 🙂

Thanks for your patience and for understanding to me non-compiler brain 😃

A static library is basically a ball of object files that haven't been turned into a proper library yet by the linker, and dlopen (the underlying APIs the interpreter uses to load libraries) only understands linker outputs. In theory the compiler could do some kind of on-the-fly linking I suppose, but no other interpreter or REPL that I know works like that, so it wouldn't be a priority.

You're right that a diagnostic would be nice; maybe if the interpreter fails to find a dynamic library it can look for a static one just to tell the developer that it's not supported.

Comment by Shai Mishali (JIRA)

Is there any way to make that pass though? e.g. using swiftc instead of swift and linking the static libraries ?

I'm not sure what you mean. swiftc and swift fundamentally do different things: one is a compiler and one is an interpreter. The fact that they share some infrastructure and command-line flags doesn't really change that.