[OE-core] [PATCH] rootfs_ipk, image: Add debug capture support

Mark Hatle mark.hatle at windriver.com
Fri Apr 26 16:05:06 UTC 2013


On 4/26/13 9:50 AM, Otavio Salvador wrote:
> On Fri, Apr 26, 2013 at 11:41 AM, Phil Blundell <pb at pbcl.net> wrote:
>> On Fri, 2013-04-26 at 09:39 -0500, Mark Hatle wrote:
>>> On 4/26/13 9:27 AM, Phil Blundell wrote:
>>>> On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
>>>>> The alternative of course is to crease special -dbg packages for the two
>>>>> conflicting items.  I.e. foo-dbg, foo-sulogin-dbg, bar-dbg and bar-sulogin-dbg...
>>>>
>>>> Yeah, indeed, that's what I suggested in my original email.  At the time
>>>> I thought that would be hard to arrange (in the general case), but
>>>> having given it some further consideration perhaps it isn't all that bad
>>>> after all.
>>>
>>> I certainly wouldn't be against an enhancement that tries to match up the
>>> binaries to their debug and create suitably named -dbg packages.  The only
>>> tricky part is what to do with the associated sources?  Since those are not
>>> arranged according to binaries, but generally for the whole recipe.
>>
>> The sources can stay where they are, in ${PN}-dbg.  There won't be any
>> conflict there because the installed files are already namespaced by
>> recipe.
>
> Maybe add a ${PN}-source with it? So any -dbg could rdepends on it?

-dbg-source would be better.. but I don't mind that.  I know there have been 
complaints where people want the debug symbols on the target, but don't want the 
debug sources.  This could address that as well.

I'd suggest someone (Phil ?) collect these and add a open an enhancement bug in 
the YP bugzilla.  That way progress on implementation can be tracked.   (Unless 
of course someone just implements it.. but I'm guessing it won't be quite that 
straightforward.)

--Mark

> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>





More information about the Openembedded-core mailing list