On 4/11/17 12:19 PM, Richard Purdie wrote:
> On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote:
>> On 4/11/17 9:56 AM, Patrick Ohly wrote:
>>>
>>> gdb-cross used to be specific to the tune flags, but isn't
>>> anymore. Therefore it is enough to use TARGET_SYS instead of
>>> TUNE_PKGARCH to create
On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote:
> On 4/11/17 9:56 AM, Patrick Ohly wrote:
> >
> > gdb-cross used to be specific to the tune flags, but isn't
> > anymore. Therefore it is enough to use TARGET_SYS instead of
> > TUNE_PKGARCH to create a unique path.
> Are you sure about this. O
On Tue, Apr 11, 2017 at 8:16 AM, Mark Hatle wrote:
> On 4/11/17 9:56 AM, Patrick Ohly wrote:
>> gdb-cross used to be specific to the tune flags, but isn't
>> anymore. Therefore it is enough to use TARGET_SYS instead of
>> TUNE_PKGARCH to create a unique path.
>
> Are you sure about this. On non-i
On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote:
> On 4/11/17 9:56 AM, Patrick Ohly wrote:
> > gdb-cross used to be specific to the tune flags, but isn't
> > anymore. Therefore it is enough to use TARGET_SYS instead of
> > TUNE_PKGARCH to create a unique path.
>
> Are you sure about this.
It'
On 4/11/17 9:56 AM, Patrick Ohly wrote:
> gdb-cross used to be specific to the tune flags, but isn't
> anymore. Therefore it is enough to use TARGET_SYS instead of
> TUNE_PKGARCH to create a unique path.
Are you sure about this. On non-intel architectures, it used to be VERY common
that the speci
gdb-cross used to be specific to the tune flags, but isn't
anymore. Therefore it is enough to use TARGET_SYS instead of
TUNE_PKGARCH to create a unique path.
Fixes a sstate signature difference that was found via
yocto-compat-layer.py's test_machine_signatures check. In practice it
probably showed
