From: "Woronicz, Bartosz ( NSN - PL/Wroclaw)" <bartosz.woronicz@nokia.com>
To: "EXT Burton, Ross" <ross.burton@intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: valgrind-native
Date: Thu, 11 Feb 2016 13:38:22 +0100 [thread overview]
Message-ID: <56BC80BE.5030707@nokia.com> (raw)
In-Reply-To: <CAJTo0Lan0mShTsA7ybk0OZH3qFmtvWpOv113Wv6V=m7BannUeg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
Hi Ross,
many thanks for nice explanation. At my shallow research, I notice, that
valgrind is somewhat special demanding packages with debugging symbols,
sooo... I actually don't need all packages to be unstripped. Only those
I am developing and testing. Therefore i might need create some class
that will require debug symbols.
And, propalby I will also need glibc with DBG symbols... or not ?
"Presumably you added BBCLASSEXTEND=native yourself, so you get to fix
it. :)"
Indeed, I did so ;-]
Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
NSN - PL/Wroclaw
On 11.02.2016 11:57, EXT Burton, Ross wrote:
> Hi,
>
> On 11 February 2016 at 10:44, Woronicz, Bartosz ( NSN - PL/Wroclaw)
> <bartosz.woronicz@nokia.com <mailto:bartosz.woronicz@nokia.com>> wrote:
>
> Any ideas why I cannot build native valgrind ?
> http://pastebin.com/e2h6AWxN
> "Missing or unbuildable dependency chain was: ['valgrind-native',
> 'glibc-dbg-native']"
>
> Also tried bitbake glibc-dbg . nothing provides that, but it is
> required in recipe
>
>
> The short answer is because valgrind doesn't have a native form yet.
> Presumably you added BBCLASSEXTEND=native yourself, so you get to fix
> it. :)
>
> valgrind RRECOMMENDS $(TCLIBC)-dbg as without debugging symbols it's
> fairly useless, and TCLIBC is the variable for the libc being used (in
> your case, glibc). As a recommends, it will be built.
>
> However, native recipes don't usually depend on the C library
> (base.bbclass handles the addition of those core dependencies, and
> doesn't run on native builds) so you've hit a new corner case.
>
> The easy fix would be to remove the recommends in the native build case:
>
> RRECOMMENDS_${PN}_class-native = ""
>
> Surprisingly enough it then builds!
>
> Also remember that we strip the native sysroot, so if you want a
> native valgrind to be useful in any way you'll have to disable that
> too (INHIBIT_SYSROOT_STRIP).
>
> (it would probably be easier to use the host valgrind, to be honest)
>
> Ross
[-- Attachment #2: Type: text/html, Size: 4431 bytes --]
next prev parent reply other threads:[~2016-02-11 12:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 10:44 valgrind-native Woronicz, Bartosz ( NSN - PL/Wroclaw)
2016-02-11 10:57 ` valgrind-native Burton, Ross
2016-02-11 12:38 ` Woronicz, Bartosz ( NSN - PL/Wroclaw) [this message]
2016-02-11 13:51 ` valgrind-native Burton, Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56BC80BE.5030707@nokia.com \
--to=bartosz.woronicz@nokia.com \
--cc=ross.burton@intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.