This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38898 Build 38897: arc lint + arc unit
Event Timeline
My goal with this patch is to eliminate some global variables from the CMake sources, which make my life harder while refactoring other parts of the build (I'm working on other, upcoming patches).
I checked that the linker script generated with this patch matched the one generated before this patch on a Docker container running Ubuntu.
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
47 | We recently made it so that the script is silent during normal operation. It looks like this adds the build output back. Could you omit this please? Successful build steps should be silent. |
Sorry, I sent the previous comment while I was still drafting.
@phosek @thakis I do have one question. Is there a reason why we want the linker script to look like
INPUT(libc++.so.1 -lunwind -lc++abi)
instead of
INPUT(libc++.so.1 -lpthread -lc <etc...> -lunwind -lc++abi)
It seems like it should be OK to include -lpthread and friends in the linker script, since we need to link against those too, no?
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
47 |
Scratch that, I was in the process of verifying the claim when I sent out the comment! So it turns out the comment is only printed when the Makefile generator is used, but I think you guys use Ninja. LMK if you still want me to remove it. Also, if you really want your build not to output anything when it's successful, there's more you need to do than just suppress these intermediate status updates, since several other tools will have intermediate output too. |
I do not know why the linker script looks like it does.
I don't particularly care about the make build's output. I weakly feel that build steps should be silent (unless they fail) in all generators (http://www.linfo.org/rule_of_silence.html), but cmake's make generator output produces pretty verbose output by default already, so it's just another broken window there.
It turns out that @EricWF was the one to originally write the script, so maybe he knows why the output is
INPUT(libc++.so.1 -lunwind -lc++abi)
instead of
INPUT(libc++.so.1 -lpthread -lc <etc...> -lunwind -lc++abi)
In case of shared libraries, the libpthread and libc dependency is already encoded in the shared library itself (e.g. in case of ELF it'd be as DT_NEEDED entries), specifying them in the linker script is not necessary and in many cases undesirable (e.g. if your application doesn't use any threading API, you probably don't want to get implicit DT_NEEDED dependency on libpthread just because you're linking libc++). Where it'd make sense is for static libraries, but we don't currently generate linker script for those.
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
46 | Would the file redirect (>) work on Windows as well? |
Ok. After r374053 and r374056, the linker script will contain the right dependencies.
I think this is good to go unless we're using a linker script on Windows and the redirection doesn't work, in which case I'll find a workaround.
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
46 | I don't think so, but would you create a linker script on Windows? I thought this was only on Linux? |
I don't think linker scripts are a thing on Window. lld-link doesn't support them. Maybe something in MinGW does, I don't know.
GNU ld does support linker script on COFF (somewhat at least, I think), but lld doesn't.
I'll go ahead with this since there doesn't seem to be a clear agreement that we need this to work on Windows.
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
42 | https://llvm.org/docs/CMake.html min requirement is 3.4.3 |
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
42 | I see a fix r374120 |
It's not about using linker scripts on Windows but cross-compiling for other systems that use linker scripts on Windows, e.g. we use linker scripts in Fuchsia and would like to build Clang toolchain including all runtimes on Windows which requires running this code when cross-compiling runtimes for Fuchsia.
This seems to have broke our build, I checked the generated linker script and it has the following format:
INPUT(libc++.so.2 -lunwind_shared -lcxxabi_shared)
libunwind and libc++abi dependencies are incorrect, it should be:
INPUT(libc++.so.2 -lunwind -lc++abi)
How do you configure your build? The paths were certainly correct when I tested this on Linux. I think this may have something to do with the fact that you use the (kind of hacky) HAVE_LIBCXXABI switch. If you let me know how you configure your build, I'll try to repro and fix it.
Oops, I didn't reload before replying. I'll follow up on https://reviews.llvm.org/D68791.
https://llvm.org/docs/CMake.html min requirement is 3.4.3
but JOIN is 3.4.12