Re: [Xen-devel] Status of 4.13

["Roger Pau Monné" <roger.pau@citrix.com>]

On Tue, Nov 26, 2019 at 09:30:47AM +0100, Jan Beulich wrote:
> On 25.11.2019 18:49, Roger Pau Monné  wrote:
> > On Mon, Nov 25, 2019 at 05:34:15PM +0000, Andrew Cooper wrote:
> >> On 25/11/2019 17:27, Roger Pau Monné wrote:
> >>> On Mon, Nov 25, 2019 at 05:07:04PM +0000, Wei Liu wrote:
> >>>> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >>>> [...]
> >>>>> Which I think it's expected, we already knew clang had a lot of
> >>>>> duplicate symbols. The only way I know to workaround this ATM is to
> >>>>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> >>>>> pile of stuff to look into, but I'm not sure when I will get to it.
> >>>> In that case we should make Gitlab CI use the new configuration option.
> >>> IMO the build should work out of the box, so we should disable
> >>> CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
> >>
> >> Kconfig in 4.13 isn't in a position to know this.  (It will be in 4.14
> >> with Anthony's refresh committed).
> > 
> > We already have Kconfig options that depend on toolchain features,
> > livepatch itself will be enabled if build id is supported by the
> > linker, why not use something like:
> 
> I'm sorry to say this, but suggesting workarounds like this when
> there's a solution to the problem [1] feels absurd.
> 
> Jan
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00357.html

IIRC Juergen had concerns about taking this after rc3. I'm all for
getting this fixed in 4.13, but if that's not the case we should just
disable live patching on clang.

Releasing without Xen building out of the box with clang is not an
option IMO.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel