Re: SDK and out of tree modules

[RUSSELL PETERSON <bluehills7@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 5475 bytes --]

I have started looking at this more closely and I have a few questions. Hope someone knows or has seen these issues before.

1. When running create_filtered task list I see failures. This is mainly due to the fact that the sdkbasepath getting renamed to tmp-renamed-sdk fails. I have bypassed this to get around it but it seems like it should work. Renaming <...>/sdk-ext/image/opt/poky/2.4.1 to <...>sdk-ext/image/tmp-renamed-sdk doesn't seem to work.

2. Understanding the sstate-cache took some time but I think I understand the basic idea now. The problem I was seeing relates to the fact that my build directory and my temp directory are on different disks. Hence, when I delete the build directory, the cache gets deleted. I would think that making core-image-full again would regenerate the sstate-cache but it does not. The only way I see the sstate-cache regenerated is by deleting the tmp directory completely and starting over. Without the cache, building the sdk-ext fails with about 5000 "should have been setscened" errors. As the ext sdk clearly has a dependency there... why isn't the state cache re-created?? Probably just don't quite understand state yet, I guess.

3. Finally, I have the ext sdk built... tried to install it... failed with an error telling me TMPDIR has changed and I need to rebuild or change it back. I assume this is related to me setting TMPDIR in the original local.conf? Anyone else see this? Seems like unless TMPDIR is set to the default (TOPDIR/tmp) the SDK won't work??

Regards,

Russell

> On July 25, 2018 at 9:01 AM RUSSELL PETERSON <bluehills7@comcast.net> wrote:
>
>
> So, this seems broken to me. I managed to get around this issue (sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) by appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp. While PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot seems to require this or it looks for the wrong manifest file.
>
> Also, when building the eSDK, dnf seems very confused about what packages are compatible. It's looking for my SoC arch packages... but then won't accept aarch64 as being compatible. I needed to set:
>
> ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"
>
> to get /etc/dnf/vars/arch to update correctly. This is a bit tedious. I'm now having a similar issue because dnf doesn't seem to like an arch of x86_64-nativesdk. Do I update ALL_MULTILIB_PACKAGE_ARCHS again?? Ug.
>
> --Russ
>
>
> > On July 24, 2018 at 8:36 AM RUSSELL PETERSON <bluehills7@comcast.net> wrote:
> >
> >
> > I am running Poky Rocko at the HEAD (just updated yesterday) and see the following when I attempt to build the eSDK:
> >
> > sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> >
> > I see this has been an issue with others as well. It looks like Paul had a fix around April but then the trail went silent so I'm not sure if there was a fix or if that fix went into Rocko. Anyone?
> >
> > --Russ
> >
> > > On July 21, 2018 at 4:42 PM Russell Peterson <bluehills7@comcast.net> wrote:
> > >
> > >
> > > No, just the standard SDK. I was having issues building the eSDK back when we used pyro and never fully figured it out… but we have since upgraded to rocko. I should revisit the eSDK and see if it works for me now or find the root cause since it sounds useful.
> > >
> > > Thanks, Khem.
> > >
> > > —Russ
> > >
> > >
> > > > On Jul 21, 2018, at 1:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > > >
> > > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson <bluehills7@comcast.net> wrote:
> > > >>
> > > >> Hello,
> > > >>
> > > >> I have been building some modules using the SDK for a while now. This is mostly for development flow purposes but we have had a few customers doing this as well. To get this to work we always need to run “make silentoldconfig scripts” inside the RFS of the SDK on the build host. Many folks forget to do this this and thus many, many questions come my way about the SDK being broken and they can’t build their modules (not all users are kernel experts or even intermediates… they just want to apply a patch and quickly move on to their app). Is there a way to do this auto-magically during the installation of the SDK by adding some type of scripts etc… to the recipe? I assume it needs to be done at install time since while the build host is x86… the exact linux distro is not known until then (or does that matter?).
> > > >>
> > > >
> > > > are you using extensible SDK ? in that case I think do_make_scripts
> > > > from module-base.bbclass should be helpful
> > > >
> > > >> —Russ
> > > >>
> > > >> --
> > > >> _______________________________________________
> > > >> yocto mailing list
> > > >> yocto@yoctoproject.org
> > > >> https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: Type: text/html, Size: 6687 bytes --]