Per [SR-404], anything that consumed libFoundation could not dynamically cast to a Foundation protocol because the build script was missing the magic swift.ld linker script to advertise the start of the protocol conformances table. (There’s also some weird issue where dlsym() seems to return the previous table if it can’t find one, but that’s a separate issue.)
The build system is opaque enough that I’m not exactly sure how the linker is driven when building shared libraries, but it would be great if the linker script was added automagically.
Per [SR-404], anything that consumed libFoundation could not dynamically cast to a Foundation protocol because the build script was missing the magic swift.ld linker script to advertise the start of the protocol conformances table.
Is it possible that the library is getting linked by clang instead of swiftc? I would expect the swiftc driver to pass the linker script down to ld (but maybe it's not).
(There’s also some weird issue where dlsym() seems to return the previous table if it can’t find one, but that’s a separate issue.)
Might be a runtime bug—are we looking up the symbol with RTLD_LOCAL?
-Joe
···
On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev <swift-dev@swift.org> wrote:
The build system is opaque enough that I’m not exactly sure how the linker is driven when building shared libraries, but it would be great if the linker script was added automagically.
You’re right, clang is being called to link. Changing to swiftc will be a bit more intrusive to the Foundation build scripts (at given my mediocre knowledge of Python) but is probably the right answer.
— Luke
···
On 31 Dec 2015, at 12:33 PM, Joe Groff <jgroff@apple.com> wrote:
On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Per [SR-404], anything that consumed libFoundation could not dynamically cast to a Foundation protocol because the build script was missing the magic swift.ld linker script to advertise the start of the protocol conformances table.
Is it possible that the library is getting linked by clang instead of swiftc? I would expect the swiftc driver to pass the linker script down to ld (but maybe it's not).
I have a longstanding desire to do this, but then we have the opposite problem: clang++ knows what extra libraries need to be added in order to link C++ code correctly, and swiftc knows what flags to use to link Swift code correctly. Of course, the libraries with Swift source have little-to-no C++ in them, so maybe it's okay.
Jordan
···
On Dec 30, 2015, at 17:49, Luke Howard via swift-dev <swift-dev@swift.org> wrote:
On 31 Dec 2015, at 12:33 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
Per [SR-404], anything that consumed libFoundation could not dynamically cast to a Foundation protocol because the build script was missing the magic swift.ld linker script to advertise the start of the protocol conformances table.
Is it possible that the library is getting linked by clang instead of swiftc? I would expect the swiftc driver to pass the linker script down to ld (but maybe it's not).
You’re right, clang is being called to link. Changing to swiftc will be a bit more intrusive to the Foundation build scripts (at given my mediocre knowledge of Python) but is probably the right answer.