[SR-359] Undef. symbols when linking to Foundation (ARM) #4199
Comments
|
Is this linking the swift standard library to the product? a verbose compile might be helpful to run here to verify. |
|
There's an interesting thing happening. I'm using Joe Bell's debian package on one machine, and the products I've built on another, and they behave differently. I noticed that Joe's version version builds and links executables against foundation, but the dredded reloc type 0x03 appears. So, I copied my version (linked with -Wl,-Bsymbolic) of libFoundation.so in place of his (leaving everything else identical) and the executable fails to build with the missing symbols: {{ Another interesting note is that it appears that the symbol is available in libswiftCore.so: {{ |
|
so is it that libFoundation.so needs -Wl,-Bsymbolic? or the stdlib? or both? |
|
So this means that a symbol is being shared across the DSO when it is not being linked with -Bsymbolic and then the scope of that symbol is somehow being dropped from the compilation unit when that is turned on (likely due to inlining). This may be an artifact of build order or the way Foundation is constructed via the partial compilation instead of the all-in-one-somewhat-like-javac-build method that the SwiftExecutable build pattern is done. |
|
stdlib is already compiled with -Wl,-Bsymbolic in my fork. Tienex has been tracking down the last few test failures in his fork. apple/swift#608 (comment) It's not clear whether foundation should be build with symbolic or not. It doesn't work either way. My guess is that it probably should be symbolic. Also, I wonder if there are paths in my version of the .so that don't match the paths that are in Joe's build products. |
|
I'll have to take your word for it on the linking process. I'm a total linking noob. |
|
From the CF standpoint it probably wouldn't make much of a difference since it should already be resilient to any failure cases of the -Bsymbolic option Here is a small diff that would apply that It builds just fine on ubuntu 14 x86_64 |
|
Using your patch it behaves just like Joe's version: reloc type 0x03. I'm not as confident about the compile command line during foundation build, though, because it doesn't respect the --verbose-build flag to build-script-impl. Building on ARM is fairly straight-forward. The only trick is getting the right repos (all the documentation in the readme applies). wdillon@raspberrypi:~ $ cat repos.sh cd swift |
|
We recently had a few updates to the linking phase that might explain some more issues here; it would be worth it to perhaps see if this is still happening. |
|
Hi Philippe, Thanks for the update. Do you have a pointer to the changes? I'd like to try this out, but I want to make sure that I have the changes locally, and that anything that I've messed with doesn't interfere. |
|
This was the commit that helped fix a few issues from the linker: |
|
Comment by Joe (JIRA) Will, Let me know when you are a ready for a build - my build area is based upon this at the moment for building on the X15: #!/bin/bash
git clone https://github.com/hpux735/swift.git swift
git clone https://github.com/apple/swift-llvm.git llvm
git clone https://github.com/apple/swift-clang.git clang
git clone https://github.com/iachievedit/swift-lldb.git lldb
git clone https://github.com/apple/swift-cmark.git cmark
git clone https://github.com/apple/swift-llbuild.git llbuild
git clone https://github.com/apple/swift-package-manager.git swiftpm
git clone https://github.com/apple/swift-corelibs-xctest.git
git clone https://github.com/apple/swift-corelibs-foundation.gitI think I can switch back to your lldb or the apple if the changes have been merged in? |
|
Go for it, Joe. I just checked, and I don't think I have any uncommitted or unmerged changes to foundation, so the Apple one is good. I'm building right now (have been for about 6-7 hours) so, we'll see. |
|
I tried it and I'm reliably getting the reloc type error I had been getting with just the stdlib formerly: wdillon@tegra-ubuntu:~$ cat frameworkTest.swift print("Foundation imports") This might actually be a positive result, because I hope it can be fixed in the same way as last time: "-Wl,-Bsymbolic" I'm trying that now. |
|
This pull request fixes it. (At least on ARMv7) |
|
I believe that this issue has been fixed by #212 |
Additional Detail from JIRA
md5: d10c8c3be55a3b67735aede67f24479b
Parent-Task:
Issue Description:
Applications linking to Framework on Linux-ARM fail to link. There are (at least) three undefined symbols:
{{wdillon@tegra-ubuntu:~$ swiftc frameworkTest.swift
/opt/apple/usr/lib/swift/linux/libFoundation.so: undefined reference to `TTSf4s_s_s_nTFs18_fatalErrorMessageFTVs12StaticStringS_S_Su_T*'
/opt/apple/usr/lib/swift/linux/libFoundation.so: undefined reference to `_TFVs13_StringBufferg9usedCountSi'
/opt/apple/usr/lib/swift/linux/libFoundation.so: undefined reference to `TTSf4sTFVs11_StringCore15_invariantCheckfT_T*'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
wdillon@tegra-ubuntu:~$
}}
The demangled references all seem to call back into string:
function signature specialization <Arg[0] = Exploded, Arg[1] = Exploded, Arg[2] = Exploded> of Swift._fatalErrorMessage (Swift.StaticString, Swift.StaticString, Swift.StaticString, Swift.UInt) -> ()
Swift._StringBuffer.usedCount.getter : Swift.Int
function signature specialization <Arg[0] = Exploded> of Swift._StringCore._invariantCheck () -> ()
Swift._fatalErrorMessage() exists in stdlib/public/core/AssertCommon.swift
The comment in the implementation of _fatalErrorMessage says that it should not be used outside of the implementation of stdlib. It's not clear why foundation would be referencing it.
The text was updated successfully, but these errors were encountered: