Discard swift.ld in favor of portable solution and support gold linker in Swift #1157
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -47,7 +47,27 @@ static void updateRuntimeLibraryPath(SearchPathOptions &SearchPathOpts, | |
| llvm::sys::path::append(LibPath, getPlatformNameForTriple(Triple)); | ||
| SearchPathOpts.RuntimeLibraryPath = LibPath.str(); | ||
|
|
||
| // The linux provided triple for ARM contains a trailing 'l' | ||
| // denoting little-endian. This is not used in the path for | ||
| // libraries. LLVM matches these SubArchTypes to the generic | ||
| // ARMSubArch_v7 (for example) type. If that is the case, | ||
| // use the base of the architecture type in the library path. | ||
| if (Triple.isOSLinux()) { | ||
|
There was a problem hiding this comment. @jrose-apple Your comment got lost again in the I've pasted it here from my email:
And I think that's a good point. I refactored it a bit, and I think that this solution really gets at the essence of what I'm trying to achieve here. The goal is to get the library path using the architecture type. In many other places in the project, "armv7" and "armv6" are used for this path according to the architecture type (not the least of which are the build and install scripts). It probably makes sense to decouple the assumption that llvm uses the same string to achieve this, or the unnecessary setting of llvm::Triple's string to match. I think it makes more sense to ask llvm for the architecture we're using, then use that to select the explicit string that we're really looking for, and is hard-coded elsewhere. With regard to the normalization logic, I did some experiments with that. It preserves the 'l' provided by linux, so it won't do what we want here. There was a problem hiding this comment. Thanks for looking into this further. This version looks good to me. There was a problem hiding this comment. …although another possible answer would be to actually use There was a problem hiding this comment. Hmmm... interesting point. Thoughts @tienex ? There was a problem hiding this comment. I still think we'll need to normalize somehow... assuming we want it to behave like clang, we should know how to translate armv7- (with no endian notion) to armv7([bl])-, the same happens for thumbv7([bl])?- which should use armv7 libraries (which effectively should be the default on linux/armv7 being the preferred ISA). There was a problem hiding this comment. Because the fact that there are still many showstopper issues with big endian (which were brought up in the discussion of the c-based implementation of the conformance objects) it may not make sense to put the cart before the horse on this one. I doubt this would pose undue complication to a future effort supporting big-endian arm cores. |
||
| switch(Triple.getSubArch()) { | ||
| default: | ||
| llvm::sys::path::append(LibPath, Triple.getArchName()); | ||
| break; | ||
| case llvm::Triple::SubArchType::ARMSubArch_v7: | ||
| llvm::sys::path::append(LibPath, "armv7"); | ||
| break; | ||
| case llvm::Triple::SubArchType::ARMSubArch_v6: | ||
| llvm::sys::path::append(LibPath, "armv6"); | ||
| break; | ||
| } | ||
| } else { | ||
| llvm::sys::path::append(LibPath, Triple.getArchName()); | ||
| } | ||
|
|
||
| SearchPathOpts.RuntimeLibraryImportPath = LibPath.str(); | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this archive these object files into static archive versions of the libraries? It seems like we don't want that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The value of SWIFT_OBJECT_{BEGIN,END} is assigned only when libkind is SHARED, so they should not be present when generating static libraries targets.