ACK/cmnt: [Xenial] SRU: Revert x86/vdso linker changes from #1830890 as this causes glibc 2.29-0ubuntu3 FTBFS on eoan

[Kleber Souza]

On 6/26/19 5:59 PM, alex.murray at canonical.com wrote:
> From: Alex Murray <alex.murray at canonical.com>
> 
> [Impact]
> As reported in #1833067 and
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1830890/comments/7
> some glibc testcases are still regressing on i386 after applying both the
> following commits:
> 
> commit 379d98ddf41344273d9718556f761420f4dc80b3
> Author: Alistair Strachan <astrachan at google.com>
> Date: Fri Aug 3 10:39:31 2018 -0700
> 
>     x86: vdso: Use $LD instead of $CC to link
> 
> commit cd01544a268ad8ee5b1dfe42c4393f1095f86879
> Author: Alistair Strachan <astrachan at google.com>
> Date: Fri Dec 14 14:36:37 2018 -0800
> 
>     x86/vdso: Pass --eh-frame-hdr to the linker
> 
> [Fix]
> Revert both these patches to restore the original behaviour.
> 
> [Test]
> ADT tests for glibc.
> 
> [Regression Potential]
> Low. This restores the status quo before the original change to
> vdso/x86/Makefile to restore the original linker behaviour.
> 
> Alex Murray (2):
>   Revert "x86/vdso: Pass --eh-frame-hdr to the linker"
>   Revert "x86: vdso: Use $LD instead of $CC to link"
> 
>  arch/x86/entry/vdso/Makefile | 22 ++++++++++++----------
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 

We can't be sure at the moment that reverting these patches will
fix the issue since we can't reproduce the problem that happens
in our build infrastructure, but according to the investigations
those are likely the cause.

I have not found a follow up fix upstream, but given that they
were applied to fix an issue that we probably don't have users
facing in Xenial (build issues with clang) reverting the changes
seems to be the quickest solution.


Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>

Thank you,
Kleber