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

["Khem Raj" <raj.khem@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

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


>
> This is not a general static linking problem,
> normal userspace code links with libc (shared or static).
>
> cu
> Adrian
>

[-- Attachment #2: Type: text/html, Size: 2382 bytes --]