For ISAR, it looks like I'm using a patched version of this 2022 commit at the moment https://github.com/ilbers/isar/commit/20af1e2798353b118fc3538da0d4cdd8866101d5 but due to upgrade to something more recent.
The `log.do_populate_sdk` file for this image recipe contains:
```
DEBUG: Executing shell function do_populate_sdk
umount: /workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/dev: not mounted
umount: /workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/proc: not mounted.
umount: /workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/sys: not mounted
find: '/workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/root': Permission denied
find: '/workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/etc/ssl/private': Permission denied
find: '/workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/var/cache/ldconfig': Permission denied
find: '/workspace/project/build/tmp/deploy/sdkchroot/debian-bullseye-armhf/var/cache/apt/archives/partial': Permission denied
NOTE: Generating SDK container in docker-archive format
DEBUG: prepare OCI container image skeleton
DEBUG: pack container image
DEBUG: Creating container image type: docker-archive
DEBUG: Converting OCI image to docker-archive
Getting image source signatures
Copying blob sha256:[hash]
Copying config sha256:[hash]
Writing manifest to image destination
Storing signatures
DEBUG: Compressing image
DEBUG: Shell function do_populate_sdk finished
```
so it's interesting that there are so many errors here when it's looks happy during the build!
On Monday, March 17, 2025 at 3:38:54 PM UTC Jan Kiszka wrote:
On 17.03.25 11:38, 'Antoine Petty' via isar-users wrote:
> For extra context, I'm using the `ghcr.io/siemens/kas/kas-isar:3.1`
> image to build the SDK in case that's relevant
Fairly old - but it should not explain the effect you are seeing.
>
> On Monday, March 17, 2025 at 10:33:59 AM UTC Antoine Petty wrote:
>
> Thanks Jan, I've given that a go but it doesn't seem to have made a
> difference.
>
> I now have e.g.
> ```
> SDK_PREINSTALL += "cmake"
> SDK_PREINSTALL += "cmake:${DISTRO_ARCH}"
> ```
> for all the SDK libraries I'm specifying
>
> When I use `bitbake -e`, `SDK_PREINSTALL=` includes e.g. `... cmake
> cmake:armhf ... libboost-all-dev libboost-all-dev:armhf ...`.
> But when spinning that up into a container, cmake isn't installed at
> all and it still looks like only the host version of boost is in the
> container. It also needed me to bump the PR in the include file to
> recognise there were changes so perhaps that's a symptom of
> something not being picked up?
Did you look into the installation logs of the SDK images? Should be
log.do_populate_sdk inside the target image recipe's workdir - IIRC.
BTW, how old is your isar revision? Not that we are hunting issues that
might have been fixed meanwhile (that meta-iot2050 layer is using a
fairly recent isar).
Jan
>
> The kas file is pointing to `debug-image` which I understand as
> being the debug-image.bb <http://debug-image.bb> file, which
> includes debug.inc where I'm adding these changes.
>
> Don't suppose you have any other ideas?
>
> Thanks
> Antoine
>
> On Friday, March 14, 2025 at 5:49:44 PM UTC Jan Kiszka wrote:
>
> On 14.03.25 17:49, 'Antoine Petty' via isar-users wrote:
> > Hi all
> >
> > I'm familiar with Yocto but fairly new to using ISAR.
> >
> > I am able to create a containerised SDK file system which
> includes the
> > libraries I'm using e.g. Boost but seems to be missing the
> additional
> > tools such as cmake.
> > It has included Boost for the host architecture but not for
> the target
> > architecture - I was expecting the target architecture
> libraries as well
> > so that I could cross-compile my application?
> >
> > I'm using KAS and my target recipe has the following:
> > ```
> > SDK_INCLUDE_ISAR_APT = "1"
> > ISAR_CROSS_COMPILE = "1"
> > SDK_FORMATS = "docker-archive"
> > SDK_PREINSTALL += "cmake"
> > SDK_PREINSTALL += "libboost-all-dev"
> > SDK_PREINSTALL += ...several other libraries and tools
> > ```
> >
> > When checking my environment with bitbake I can see
> > `DISTRO_ARCH="armhf"`. I can see my container has the g++ etc
> cross-
> > compilers for this architecture which I assume is triggered by
> this
> > variable.
> >
> > So in summary, I have two problems:
> >
> > 1. Missing tools specified in `SDK_PREINSTALL`
> > 2. Missing cross-compiled dependencies such as Boost
> >
> > Am I doing something wrong or misunderstanding how this works?
> >
> > Thank you :)
> >
>
> When cross-compiling, you will generally have to specific the
> arch for
> the extra SDK dev packages. See e.g. here:
>
> https://github.com/siemens/meta-iot2050/blob/
> bb0721efdaa67aee7702aacef6f5709d7a0b33bb/conf/distro/iot2050-
> debian.conf#L35 <https://github.com/siemens/meta-iot2050/blob/
> bb0721efdaa67aee7702aacef6f5709d7a0b33bb/conf/distro/iot2050-
> debian.conf#L35>
>
> It that also does not help, check via "bitbake -e" which value
> SDK_PREINSTALL actually gets assigned in the end.
>
> Jan
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center
>
> --
> You received this message because you are subscribed to the Google
> Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isar-users+...@googlegroups.com <mailto:isar-
> users+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/isar-
> users/4bb71134-721d-4eec-9a17-fbbd693c1d58n%40googlegroups.com <https://
> groups.google.com/d/msgid/isar-users/4bb71134-721d-4eec-9a17-
> fbbd693c1d58n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
Siemens AG, Foundational Technologies
Linux Expert Center
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/3daa7f3f-1a95-4fed-bcdc-5251908c776fn%40googlegroups.com.