Add support to build cobalt/starboard using an external RDK toolchain - #5166

Note that these changes currently disable .rsp files as it breaks the build when using the external RDK toolchain - looking into it.

apart from the the open comments lgtm!

@andrunko can you see why the required checks are failing . maybe rerun the failing checks to ensure there's no flakes.

@andrunko can you see why the required checks are failing . maybe rerun the failing checks to ensure there's no flakes.

The failures seem to be caused by this line on docker-compose.yml:

    - ${RDK_SDK:-.}:${RDK_SDK}

This was added to support users extracting the SDK anywhere, as the SDK executables expect their path to be the same as the one where they got extracted to, so we need to mount the SDK in the same place inside the container where it was extracted outside the container.

I was initially mounting $HOME:$HOME here, but this would only work if the SDK is extracted somewhere inside $HOME outside the container as well. I changed it after #5166 (comment), which would solve the issue when mounting outside $HOME, but would also require all containers to have RDK_SDK set.

Note we only need that until we get the sysroot uploaded somewhere public, then we can extract it directly from the docker container anywhere and set the env vars accordingly.

For now, the options I can see:

• mount $HOME and ask any user trying to build for RDK to extract the sysroot inside their $HOME as well
  • this considers CI has $HOME set, which is likely
• always set RDK_SDK for all CI jobs

Thoughts?

@andrunko can you see why the required checks are failing . maybe rerun the failing checks to ensure there's no flakes.

The failures seem to be caused by this line on docker-compose.yml:

    - ${RDK_SDK:-.}:${RDK_SDK}

This was added to support users extracting the SDK anywhere, as the SDK executables expect their path to be the same as the one where they got extracted to, so we need to mount the SDK in the same place inside the container where it was extracted outside the container.

I was initially mounting $HOME:$HOME here, but this would only work if the SDK is extracted somewhere inside $HOME outside the container as well. I changed it after #5166 (comment), which would solve the issue when mounting outside $HOME, but would also require all containers to have RDK_SDK set.

Note we only need that until we get the sysroot uploaded somewhere public, then we can extract it directly from the docker container anywhere and set the env vars accordingly.

For now, the options I can see:

• mount $HOME and ask any user trying to build for RDK to extract the sysroot inside their $HOME as well

  • this considers CI has $HOME set, which is likely

• always set RDK_SDK for all CI jobs

Thoughts?

@oxve thoughts? the HOME option sounds like what we would use currently

if possible, try not to ask the user to install the SDK in $HOME. On some partner environment, they have very limited disc quota at $HOME because it is system disc. but they have large shared work space mounted on other paths. And engineers from the same partner can share the installed SDK if it is installed in system folder. Having a symbolic link in $HOME might not solve the issue but it is not straightforward.

Can we set the RDK_SDK using ENV in Dockerfile which point to the default value we expected to be installed? And partner can overwrite it if they specifically set the value in bash env?

the rest of changes look good to me

if possible, try not to ask the user to install the SDK in $HOME. On some partner environment, they have very limited disc quota at $HOME because it is system disc. but they have large shared work space mounted on other paths. And engineers from the same partner can share the installed SDK if it is installed in system folder. Having a symbolic link in $HOME might not solve the issue but it is not straightforward.

Can we set the RDK_SDK using ENV in Dockerfile which point to the default value we expected to be installed? And partner can overwrite it if they specifically set the value in bash env?

We cant use ENV as the sysroot needs to be mounted inside the container exactly in the same location it was extracted outside the container. I've updated the PR again to use HOME for now (which in theory should solve the checks here), but another option would be to have a fixed location where the sysroot needs to be extracted (outside the container), and then we mount this hardcoded location in the same place inside the container - e.g. /opt/rdk-sysroot or something like that.

Please let me know what you think and if you decide on a hardcoded path, which one we should use here.

if possible, try not to ask the user to install the SDK in $HOME. On some partner environment, they have very limited disc quota at $HOME because it is system disc. but they have large shared work space mounted on other paths. And engineers from the same partner can share the installed SDK if it is installed in system folder. Having a symbolic link in $HOME might not solve the issue but it is not straightforward.
Can we set the RDK_SDK using ENV in Dockerfile which point to the default value we expected to be installed? And partner can overwrite it if they specifically set the value in bash env?

We cant use ENV as the sysroot needs to be mounted inside the container exactly in the same location it was extracted outside the container. I've updated the PR again to use HOME for now (which in theory should solve the checks here), but another option would be to have a fixed location where the sysroot needs to be extracted (outside the container), and then we mount this hardcoded location in the same place inside the container - e.g. /opt/rdk-sysroot or something like that.

Please let me know what you think and if you decide on a hardcoded path, which one we should use here.

Using a hardcoded path could also make the checks here fail, e.g. if we try to mount /opt/rdk-sysroot:/opt/rdk-sysroot but this dir doesnt exist outside the container (on CI), the checks will likely fail.

Tbh the best I can think atm is to use $HOME until we get the public sysroot available, then we get rid of all this.

The new CI failures seem unrelated?

Post job cleanup.
/usr/local/bin/docker exec  5a6448ea877[2](https://github.com/youtube/cobalt/actions/runs/14394116159/job/40367256156?pr=5166#step:30:2)49e4e732fbba93873e66026e230ab1b9b8c4691aec1452b4f5df sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)