- User Since
- Oct 18 2019, 11:34 AM (4 w, 6 d)
Thu, Oct 31
Thanks everyone! It was a great learning experience getting this patch in and learning more about building/testing LLVM!
Wed, Oct 30
Can someone please commit this for me if everyone is happy with it now?
Updated the tests with @jhenderson comments.
Fixed all outstanding comments with documentation, test cases and linking to the correct upstream bug.
Mon, Oct 28
I totally defer to you guys on if this is something you want to accept or not. We are now patching our own toolchain with this patch to not create bad binaries. If I where to make a case for accepting this patch it would be something like:
Thu, Oct 24
@rupprecht - Thanks! I have addressed the comments and uploaded a new rev. Hope I did it correctly. I don't have commit access - if you could commit it for me it would be great. I might have other patches in the future (looking at you MingW driver) but I'll cross that bridge then.
This revision should address all the comments in the previous revision. Comments are updated, testing --strip-all-gnu and documentation changes. Let me know if you have additional comments.
Oct 21 2019
Thanks everyone for the feedback. I was meeting up with our QA team this week and they said that they seen the issue with these binaries on a much larger array of devices than I initially thought. This is not a bug in upstream GLIBC - this is a bug in debian/ubuntu versions that patch glibc to specifically check for SHT_ARM_ATTRIBUTES. We tested with all debian based NAS devices we had and saw the same issue. We even tested with raspbian on raspberry pi and this also contains the issue.