On Thu, May 14, 2020 at 07:48:28AM -0700, Khem Raj wrote: > On Thu, May 14, 2020 at 7:07 AM Adrian Bunk <b...@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 <b...@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 <b...@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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138270): https://lists.openembedded.org/g/openembedded-core/message/138270 Mute This Topic: https://lists.openembedded.org/mt/74142400/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
