Re: [OE-core] [PATCH V3 3/3] gcc10: Revert using __getauxval in libgcc

["Adrian Bunk" <bunk@stusta.de>]

On Thu, May 14, 2020 at 07:48:28AM -0700, Khem Raj wrote:
> On Thu, May 14, 2020 at 7:07 AM Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Thu, May 14, 2020 at 06:56:07AM -0700, Khem Raj wrote:
> > > On Thu, May 14, 2020 at 6:16 AM Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > > On Thu, May 14, 2020 at 05:47:48AM -0700, Khem Raj wrote:
> > > > > On Thu, May 14, 2020 at 12:38 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > > > > On Mon, May 11, 2020 at 11:28:12AM -0700, Khem Raj wrote:
> > > > > > > This was added recently, but it seems be chewing more than what
> > it
> > > > > > > should and causes non glibc packages also depend on it.
> > > > > > >...
> > > > > >
> > > > > > Is this only valgrind (there is a upstream bug open for that),
> > > > > > or were there more recipes with a problem?
> > > > >
> > > > > Just valgrind but problem can happen with static linking with no
> > default
> > > > > libs in general
> > > >
> > > > No, it cannot.
> > > > The relevant part of "no default libs" is not linking with libc.
> > > >
> > > > Linking statically with libgcc and then providing own implementations
> > > > of all libc functions used by libgcc instead of linking with libc is
> > > > not a common situation.
> > >
> > > Take a look At what’s going on in valgrind memcheck build if you are
> > > interested perhaps you will find something which is not yet understood
> >
> > Memcheck links statically with libgcc, and it does not link with libc.
> 
> Ok what happens when you link it with libc
>...

I do not even want to know how that explodes.

cu
Adrian