SDK Container for app development is missing some applications

[Antoine Petty]

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 :)

[Jan Kiszka]

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

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

[Antoine Petty]

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?

The kas file is pointing to `debug-image` which I understand as being the debug-image.bb file, which includes debug.inc where I'm adding these changes.

Don't suppose you have any other ideas?

Thanks

Antoine

[Antoine Petty]

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

[Jan Kiszka]

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

> 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>.

[Antoine Petty]

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!

[Jan Kiszka]

On 18.03.25 12:27, 'Antoine Petty' via isar-users wrote:
> 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.

Could you please clarify the exact version in use in the end? kas is
reporting that revision while starting up (I strongly suspect you are
using kas).

Yeah, but those are misleading.

I also asked for the wrong log files. We need to look at the recipe
<image-name>-sdk, task do_rootfs_install.