- User Since
- Aug 15 2016, 6:00 AM (118 w, 2 d)
LGTM (assuming you've tested it).
This particular build method uses system-wide installation of these tools.
I would like to request reverting this. It's established standard within LLVM to explicitly specify the dependencies the particular test suite relies on.
Tue, Nov 20
Sun, Nov 18
Updated for check order change in master.
LGTM. There's no terminfo on Linux (or majority of other systems, I suppose), so this shouldn't break anything. I've tested it on Linux, tests pass and there's no perceivable difference ;-).
Fri, Nov 16
Well, sure but I think changing the order should be done separately from this. I'm fixing a bug resulting from people deciding to customize code instead of keeping it in sync; so I'd rather not combine it with intentionally mis-syncing the code.
Sat, Nov 10
Merged. I will get back to you if something explodes ;-).
Could you please rebase? I'm pretty sure this breaks our use but I can't test since it no longer applies cleanly.
Also please remember to submit patches with -U9999, so that Phab has full context.
Tue, Nov 6
This isn't normally used on Linux since .preinit_array is used. If I force it, I get the following warning (from gcc):
Sat, Nov 3
Implemented all comments + moved CHECK_UNSUPPORTED below faster R+W checks.
Tue, Oct 30
@philip.pfaffe, did you establish whether this is still necessary or can be abandoned?
LGTM, presuming the tests pass for you.
Oct 18 2018
Oct 16 2018
Thanks for the review. I'm going to be away most of the day today, so if it breaks something (worse), feel free to revert.
Thanks for all your reports. I have filed https://reviews.llvm.org/D53326 to disable the tests on all three known-broken arches.
Oct 15 2018
The first one seems to indicate that your libclang.so is broken in release mode (optimization error?). The second one is correct (some of the tests test for errors, and apparently don't silence the messages).
Oct 14 2018
I think there's some confusion here. This has nothing to do with libsupc++ but FWIU with gcc's libunwind header which is apparently used when compiling it with gcc.
Oct 13 2018
WFM. Thanks for analyzing the problem.
Oct 12 2018
Do you have any clue how to solve this? Or should I just if() the tests out of Windows?
Thanks for the review!
Oct 11 2018
Unless my bisect is mistaken, this broke Clang Python binding test:
Please review the new version, addressing the issue caught by buildbots.
v3: one more correction for stand-alone builds.
v2: fixed appending to check-all to make it compatible both with in-tree and standalone builds
To be honest, I'm not really convinced this is the best way to do it. I don't really know why GCC's libunwind doesn't declare those constants, and I have no clue what the implications of forcing them on top of possibly-gcc libunwind might be.
Oct 10 2018
@bebuch, I agree with @mclow.lists here that the new errors are completely unrelated to the problem solved by this patch, and the fix to it belongs in a separate changeset. Can we get the original problem fixed first then?
Oct 7 2018
@mclow.lists , ping. Any chance to get a proper version upstream? I'd rather not pull patches from Fedora when we can have something official.
Oct 3 2018
Yes, I've tested it on Linux. I'll commit it once the dep is approved, and hopefully build bots will answer if they work across all platforms.
To avoid consumers of the bindings, I've changed the patch to set the path only through tests. As a result, the binding API is unchanged.
Oct 2 2018
Thanks. I can confirm that it fixes installing libsupc++ headers for us on the main ABI. Apparently the headers in 32-bit multilib build aren't installed but I see the same issue with libcxx-6.0.1, so it's not a regression (and probably a bug on our end).