- User Since
- Feb 11 2015, 3:26 PM (243 w, 4 d)
Fri, Oct 11
@phosek Can you please confirm this also fixes your issue in the Runtimes build?
CMake tracks dependencies between targets, but not between directories. If the CMakeLists.txt in some directory (e.g. <root>/libcxx/) needs a target defined in another directory (e.g. <root>/libcxxabi/), one has to make sure that libcxxabi's CMakeLists.txt is included before libcxx's CMakeLists.txt. This isn't new or vexing, IMO. If that is what this patch ensures (I don't know the runtimes build very well), I think this is good.
Thu, Oct 10
Wed, Oct 9
You have commit access, right? If so, go ahead. Otherwise, LMK and I can commit this for you.
Tue, Oct 8
I'll go ahead with this since there doesn't seem to be a clear agreement that we need this to work on Windows.
Like Richard said before, we can't switch type traits to aliases. However, we can always do:
Mon, Oct 7
It turns out that @EricWF was the one to originally write the script, so maybe he knows why the output is
Fri, Oct 4
So, the problem with this patch as it stands is that it introduces a link-time dependency from libc++abi back to libc++, because libc++abi needs the definition of new and delete (which would be in libc++ only with this patch). This is what I'm working around in the tests by re-adding -lc++ after -lc++abi on the compiler command line. This isn't a problem on Apple platforms IIUC since the order of command-line -l<xxx> arguments doesn't matter, but it does for linkers on most other platforms.
I kinda like the suggestion. I'm pretty confident we don't support compilers that don't implement __has_include anyway (maybe we technically do, but I'm sure nothing good happens in that case).
Thu, Oct 3
I'll pick this up. I wasn't aware you had started working on this, but thanks!
Wed, Oct 2
This looks roughly okay to me, but I don't maintain the Windows side of things (I don't really run tests on Windows except when required to). I would wait for @EricWF or other folks that work on Windows more often to give you a thumbs up before committing this.
Sorry, I sent the previous comment while I was still drafting.
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).
Tue, Oct 1
Okay, so after speaking to our linker folks a while ago, I decided to drop this.
It turns out the GCC problem was only due to the linker not resolving the undefined new/delete references in libc++abi to libc++. Adding another -lc++ after -lc++abi fixes the issue.
Fix linker error with GCC