Getting TI tools into [host] SDK

Getting TI tools into [host] SDK

[Gary Thomas]

I'm trying to build a [host] SDK for my target which uses some
TI tools, via -c populate_sdk_ext

In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
I include ti-cgt-pru in my target image to get the tools on my board - that also works.

The problem is that in my SDK, none of the binaries are included, including clpru:

$ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
total 16
drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib

I added this to try and include the files:
   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
executables included, they just aren't being packaged.

$ ls 
tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
abspru    arpru   cgpru     clpru   dispru    hexpru  libinfopru  nmpru   optpru    xrefpru
acpiapru  asmpru  clistpru  dempru  embedpru  ilkpru  lnkpru      ofdpru  strippru

Any ideas on what I need to do to get the binary executables into my SDK?

Note: I copied just those (bin) files into my SDK target sysroot usr/bin and the compiler
runs just fine.  I just need to figure out the recipe magic to make this happen.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Getting TI tools into [host] SDK

[Khem Raj]

On 17-03-08 09:10:18, Gary Thomas wrote:
> I'm trying to build a [host] SDK for my target which uses some
> TI tools, via -c populate_sdk_ext
> 
> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
> 
> The problem is that in my SDK, none of the binaries are included, including clpru:
> 
> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
> total 16
> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
> 
> I added this to try and include the files:
>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
> executables included, they just aren't being packaged.
> 
> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin

perhaps you need to correct the install location for nativesdk may be
via overriding do_install

> abspru    arpru   cgpru     clpru   dispru    hexpru  libinfopru  nmpru   optpru    xrefpru
> acpiapru  asmpru  clistpru  dempru  embedpru  ilkpru  lnkpru      ofdpru  strippru
> 
> Any ideas on what I need to do to get the binary executables into my SDK?
> 
> Note: I copied just those (bin) files into my SDK target sysroot usr/bin and the compiler
> runs just fine.  I just need to figure out the recipe magic to make this happen.
> 
> Thanks
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> -- 
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: Getting TI tools into [host] SDK

[Denys Dmytriyenko]

On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
> On 17-03-08 09:10:18, Gary Thomas wrote:
> > I'm trying to build a [host] SDK for my target which uses some
> > TI tools, via -c populate_sdk_ext

Gary,

We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
old meta-toolchain mechanism. First, because it can be incorporated into other 
recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
Second, it provides more control to what get's packaged into SDK. Third, it 
doesn't have this undefined magic to packaging stuff - i.e. this post is an 
example of it failing. And only one slight drawback - requires keeping rootfs 
image recipe in sync with meta-toolchain SDK recipe...


> > In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
> > I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
> > I include ti-cgt-pru in my target image to get the tools on my board - that also works.
> > 
> > The problem is that in my SDK, none of the binaries are included, including clpru:
> > 
> > $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
> > total 16
> > drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
> > drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
> > 
> > I added this to try and include the files:
> >   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
> > and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
> > executables included, they just aren't being packaged.
> > 
> > $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
> 
> perhaps you need to correct the install location for nativesdk may be
> via overriding do_install

Why?

-- 
Denys


> > abspru    arpru   cgpru     clpru   dispru    hexpru  libinfopru  nmpru   optpru    xrefpru
> > acpiapru  asmpru  clistpru  dempru  embedpru  ilkpru  lnkpru      ofdpru  strippru
> > 
> > Any ideas on what I need to do to get the binary executables into my SDK?
> > 
> > Note: I copied just those (bin) files into my SDK target sysroot usr/bin and the compiler
> > runs just fine.  I just need to figure out the recipe magic to make this happen.

Re: Getting TI tools into [host] SDK

[Khem Raj]

On 3/10/17 5:47 PM, Denys Dmytriyenko wrote:
> On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
>> On 17-03-08 09:10:18, Gary Thomas wrote:
>>> I'm trying to build a [host] SDK for my target which uses some
>>> TI tools, via -c populate_sdk_ext
> 
> Gary,
> 
> We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
> old meta-toolchain mechanism. First, because it can be incorporated into other 
> recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
> Second, it provides more control to what get's packaged into SDK. Third, it 
> doesn't have this undefined magic to packaging stuff - i.e. this post is an 
> example of it failing. And only one slight drawback - requires keeping rootfs 
> image recipe in sync with meta-toolchain SDK recipe...
> 
> 
>>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
>>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
>>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
>>>
>>> The problem is that in my SDK, none of the binaries are included, including clpru:
>>>
>>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
>>> total 16
>>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
>>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
>>>
>>> I added this to try and include the files:
>>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
>>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
>>> executables included, they just aren't being packaged.
>>>
>>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
>>
>> perhaps you need to correct the install location for nativesdk may be
>> via overriding do_install
> 
> Why?
> 

because  /usr/share doesnt look normal place for putting executables.

Re: Getting TI tools into [host] SDK

[Denys Dmytriyenko]

On Fri, Mar 10, 2017 at 06:00:20PM -0800, Khem Raj wrote:
> 
> 
> On 3/10/17 5:47 PM, Denys Dmytriyenko wrote:
> > On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
> >> On 17-03-08 09:10:18, Gary Thomas wrote:
> >>> I'm trying to build a [host] SDK for my target which uses some
> >>> TI tools, via -c populate_sdk_ext
> > 
> > Gary,
> > 
> > We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
> > old meta-toolchain mechanism. First, because it can be incorporated into other 
> > recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
> > Second, it provides more control to what get's packaged into SDK. Third, it 
> > doesn't have this undefined magic to packaging stuff - i.e. this post is an 
> > example of it failing. And only one slight drawback - requires keeping rootfs 
> > image recipe in sync with meta-toolchain SDK recipe...
> > 
> > 
> >>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
> >>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
> >>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
> >>>
> >>> The problem is that in my SDK, none of the binaries are included, including clpru:
> >>>
> >>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
> >>> total 16
> >>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
> >>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
> >>>
> >>> I added this to try and include the files:
> >>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
> >>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
> >>> executables included, they just aren't being packaged.
> >>>
> >>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
> >>
> >> perhaps you need to correct the install location for nativesdk may be
> >> via overriding do_install
> > 
> > Why?
> 
> because  /usr/share doesnt look normal place for putting executables.

True in general, but that shouldn't matter. FILES_${PN} lists those and that 
should be enough. It appears you are just guessing...

Sidenote:
This PRU CodeGen toolchain is kind of weird - it targets PRUs (Programmable 
Real-time Units http://elinux.org/Ti_AM33XX_PRUSSv2) and provides binaries in 
bin/, headers in include/ and libraries in lib/ directories. Some of the names 
collide with system (e.g. libc.a) and hence cannot be installed in standard 
locations, thus /usr/share. In fact, many of non-Linux specific components 
that deal with specialized cores (i.e. non-general-purpose ARM, such as DSP, 
PRU, IPU, numerous Cortex-M accelerators, etc.) are in fact as weird and are 
also getting installed in /usr/share to not confuse people and not conflict 
with the rest of the system...

-- 
Denys

Re: Getting TI tools into [host] SDK

[Khem Raj]

On 3/10/17 6:27 PM, Denys Dmytriyenko wrote:
> On Fri, Mar 10, 2017 at 06:00:20PM -0800, Khem Raj wrote:
>>
>>
>> On 3/10/17 5:47 PM, Denys Dmytriyenko wrote:
>>> On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
>>>> On 17-03-08 09:10:18, Gary Thomas wrote:
>>>>> I'm trying to build a [host] SDK for my target which uses some
>>>>> TI tools, via -c populate_sdk_ext
>>>
>>> Gary,
>>>
>>> We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
>>> old meta-toolchain mechanism. First, because it can be incorporated into other 
>>> recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
>>> Second, it provides more control to what get's packaged into SDK. Third, it 
>>> doesn't have this undefined magic to packaging stuff - i.e. this post is an 
>>> example of it failing. And only one slight drawback - requires keeping rootfs 
>>> image recipe in sync with meta-toolchain SDK recipe...
>>>
>>>
>>>>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
>>>>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
>>>>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
>>>>>
>>>>> The problem is that in my SDK, none of the binaries are included, including clpru:
>>>>>
>>>>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
>>>>> total 16
>>>>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
>>>>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
>>>>>
>>>>> I added this to try and include the files:
>>>>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
>>>>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
>>>>> executables included, they just aren't being packaged.
>>>>>
>>>>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
>>>>
>>>> perhaps you need to correct the install location for nativesdk may be
>>>> via overriding do_install
>>>
>>> Why?
>>
>> because  /usr/share doesnt look normal place for putting executables.
> 
> True in general, but that shouldn't matter. FILES_${PN} lists those and that 
> should be enough. It appears you are just guessing...
> 
> Sidenote:
> This PRU CodeGen toolchain is kind of weird - it targets PRUs (Programmable 
> Real-time Units http://elinux.org/Ti_AM33XX_PRUSSv2) and provides binaries in 
> bin/, headers in include/ and libraries in lib/ directories. Some of the names 
> collide with system (e.g. libc.a) and hence cannot be installed in standard 
> locations, thus /usr/share. In fact, many of non-Linux specific components 
> that deal with specialized cores (i.e. non-general-purpose ARM, such as DSP, 
> PRU, IPU, numerous Cortex-M accelerators, etc.) are in fact as weird and are 
> also getting installed in /usr/share to not confuse people and not conflict 
> with the rest of the system...
> 

it would be better to have multiple sysroots for all these variants
would be way simpler and understandable, but why do I care.

Re: Getting TI tools into [host] SDK

[Denys Dmytriyenko]

On Fri, Mar 10, 2017 at 06:45:00PM -0800, Khem Raj wrote:
> 
> 
> On 3/10/17 6:27 PM, Denys Dmytriyenko wrote:
> > On Fri, Mar 10, 2017 at 06:00:20PM -0800, Khem Raj wrote:
> >>
> >>
> >> On 3/10/17 5:47 PM, Denys Dmytriyenko wrote:
> >>> On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
> >>>> On 17-03-08 09:10:18, Gary Thomas wrote:
> >>>>> I'm trying to build a [host] SDK for my target which uses some
> >>>>> TI tools, via -c populate_sdk_ext
> >>>
> >>> Gary,
> >>>
> >>> We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the 
> >>> old meta-toolchain mechanism. First, because it can be incorporated into other 
> >>> recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball. 
> >>> Second, it provides more control to what get's packaged into SDK. Third, it 
> >>> doesn't have this undefined magic to packaging stuff - i.e. this post is an 
> >>> example of it failing. And only one slight drawback - requires keeping rootfs 
> >>> image recipe in sync with meta-toolchain SDK recipe...
> >>>
> >>>
> >>>>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
> >>>>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
> >>>>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
> >>>>>
> >>>>> The problem is that in my SDK, none of the binaries are included, including clpru:
> >>>>>
> >>>>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
> >>>>> total 16
> >>>>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
> >>>>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
> >>>>>
> >>>>> I added this to try and include the files:
> >>>>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
> >>>>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
> >>>>> executables included, they just aren't being packaged.
> >>>>>
> >>>>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
> >>>>
> >>>> perhaps you need to correct the install location for nativesdk may be
> >>>> via overriding do_install
> >>>
> >>> Why?
> >>
> >> because  /usr/share doesnt look normal place for putting executables.
> > 
> > True in general, but that shouldn't matter. FILES_${PN} lists those and that 
> > should be enough. It appears you are just guessing...
> > 
> > Sidenote:
> > This PRU CodeGen toolchain is kind of weird - it targets PRUs (Programmable 
> > Real-time Units http://elinux.org/Ti_AM33XX_PRUSSv2) and provides binaries in 
> > bin/, headers in include/ and libraries in lib/ directories. Some of the names 
> > collide with system (e.g. libc.a) and hence cannot be installed in standard 
> > locations, thus /usr/share. In fact, many of non-Linux specific components 
> > that deal with specialized cores (i.e. non-general-purpose ARM, such as DSP, 
> > PRU, IPU, numerous Cortex-M accelerators, etc.) are in fact as weird and are 
> > also getting installed in /usr/share to not confuse people and not conflict 
> > with the rest of the system...
> 
> it would be better to have multiple sysroots for all these variants
> would be way simpler and understandable, but why do I care.

Unfortunately, OE doesn't easily support separate sysroots for "secondary" 
processors, besides host and target, like DSP. We had looked into that long 
time ago w/o much success. If you have any suggestions or recommendations, I'm 
all ears!

-- 
Denys

Re: Getting TI tools into [host] SDK

[Gary Thomas]

On 2017-03-11 02:47, Denys Dmytriyenko wrote:
> On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
>> On 17-03-08 09:10:18, Gary Thomas wrote:
>>> I'm trying to build a [host] SDK for my target which uses some
>>> TI tools, via -c populate_sdk_ext
>
> Gary,
>
> We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the
> old meta-toolchain mechanism. First, because it can be incorporated into other
> recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball.
> Second, it provides more control to what get's packaged into SDK. Third, it
> doesn't have this undefined magic to packaging stuff - i.e. this post is an
> example of it failing. And only one slight drawback - requires keeping rootfs
> image recipe in sync with meta-toolchain SDK recipe...

As I understand, the meta-toolchain style(s) are deprecated.  Also using the
populate_sdk_ext gets me many improvements such as relocatable tools and 'devtool'

>
>
>>> In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
>>> I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
>>> I include ti-cgt-pru in my target image to get the tools on my board - that also works.
>>>
>>> The problem is that in my SDK, none of the binaries are included, including clpru:
>>>
>>> $ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
>>> total 16
>>> drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
>>> drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
>>>
>>> I added this to try and include the files:
>>>   TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
>>> and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
>>> executables included, they just aren't being packaged.
>>>
>>> $ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
>>
>> perhaps you need to correct the install location for nativesdk may be
>> via overriding do_install
>
> Why?
>


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Getting TI tools into [host] SDK

[Denys Dmytriyenko]

On Sat, Mar 11, 2017 at 06:00:24AM +0100, Gary Thomas wrote:
> On 2017-03-11 02:47, Denys Dmytriyenko wrote:
> >On Wed, Mar 08, 2017 at 09:03:28AM -0800, Khem Raj wrote:
> >>On 17-03-08 09:10:18, Gary Thomas wrote:
> >>>I'm trying to build a [host] SDK for my target which uses some
> >>>TI tools, via -c populate_sdk_ext
> >
> >Gary,
> >
> >We don't use -c populate_sdk to produce SDKs. Instead, we still rely on the
> >old meta-toolchain mechanism. First, because it can be incorporated into other
> >recipes - i.e. we have a recipe that combines rootfs and SDK into one tarball.
> >Second, it provides more control to what get's packaged into SDK. Third, it
> >doesn't have this undefined magic to packaging stuff - i.e. this post is an
> >example of it failing. And only one slight drawback - requires keeping rootfs
> >image recipe in sync with meta-toolchain SDK recipe...
> 
> As I understand, the meta-toolchain style(s) are deprecated.

Seems to still work fine here...


> Also using the populate_sdk_ext gets me many improvements such as 
> relocatable tools and 'devtool'

Yes, this one I can agree with - it's a nice addition to eSDK. But what about 
this one:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/meta-extsdk-toolchain.bb


> >>>In particular, I'm using recipes-ti/devtools/ti-cgt-pru_2.1.4.bb
> >>>I include ti-cgt-pru-native to use the tools in my bitbake recipes - that works fine.
> >>>I include ti-cgt-pru in my target image to get the tools on my board - that also works.
> >>>
> >>>The problem is that in my SDK, none of the binaries are included, including clpru:
> >>>
> >>>$ ls -l /home/gthomas/my_ti_sdk/tmp/sysroots/rainier-p8701/usr/share/ti/cgt-pru
> >>>total 16
> >>>drwxrwxr-x 2 gthomas gthomas 12288 Mar  8 08:22 include
> >>>drwxrwxr-x 3 gthomas gthomas  4096 Mar  8 08:22 lib
> >>>
> >>>I added this to try and include the files:
> >>>  TOOLCHAIN_HOST_TASK += "'nativesdk-ti-cgt-pru"
> >>>and I can see that there was a nativesdk-ti-cgt-pru built which does have all the
> >>>executables included, they just aren't being packaged.
> >>>
> >>>$ ls tmp/work/x86_64-nativesdk-mysdk-linux/nativesdk-ti-cgt-pru/2.1.4-r0/image/opt/mydistro/2.2+snapshot/sysroots/x86_64-amltdsdk-linux/usr/share/ti/cgt-pru/bin
> >>
> >>perhaps you need to correct the install location for nativesdk may be
> >>via overriding do_install
> >
> >Why?
> >
> 
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------