[compiler-rt] r184805 - Remove the sysroot (or isysroot) restriction from the GCDAProfile.c
Bob Wilson
bob.wilson at apple.com
Tue Jun 25 22:46:28 PDT 2013
On Jun 25, 2013, at 5:11 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Tue, Jun 25, 2013 at 2:44 PM, Bob Wilson <bob.wilson at apple.com> wrote:
> OK, I think I managed to get our buildbots unblocked. We have some internal code to add armv7s, which wasn't disabled by the hack in 184816. I've fixed that now, so hopefully our buildbots will start passing again.
>
> But, we still need a real solution. It looks like we just need to add errno.h to the fake SDK for Darwin. Or is the problem more fundamental than that?
>
> I don't have strong opinions here.
>
> I can't readily add an errno.h (or anything else) to the fake SDK for Darwin because I have no idea what to put in it. If you guys want to do that, cool. Personally, I don't like the idea of using a fake SDK for this at all. Instead, I much prefer that the build system test for the existence of the real SDK and use it to build the library.
>
> That said, I'm also fine with making the use of the actual libc system headers be Linux-only if you guys really need to continue to do the fake SDK thing. I think Bill has already implemented this, and it looks like a good solution to me.
>
> Ultimately, the only thing I really care about is being able to add the code to this library necessary to make failures encountered in it debuggable on Linux. I actually think the current approach works just fine for this (using __APPLE__ to hide the errno business) but will leave it to you guys to revert the changes to clang_darwin.mk when you're comfortable with tho solution.
Unfortunately we’re going to need to continue using the fake SDK approach for Darwin, at least for Apple’s builds. I’m not a fan either, but we haven’t been able to come up with any reasonable alternative.
We can either add errno.h to the fake SDK for Darwin or keep Bill’s __APPLE__ ifdef workaround. With that in place now, can we revert at least the clang_darwin.mk parts of 184805? I assume you want to keep the clang_linux.mk change to avoid using the fake SDK for the profiling library, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130625/dee43b84/attachment.html>
More information about the llvm-commits
mailing list