BSP 6.8.5: yocto build fails for elfutils

Technical Support
, , ,
1

Hello,

when using the new BSP 6.8.5 with the default torizoncore manifest I get an error building the elfutils recipe:

$ mkdir test
$ cd test
$ repo init -u https://git.toradex.com/toradex-manifest.git -b refs/tags/6.8.5 -m torizoncore/default.xml
$ repo sync
$ MACHINE=verdin-imx8mm EULA=1 source setup-environment
$ bitbake elfutils

| ../../elfutils-0.186/debuginfod/debuginfod-client.c:1158:11: error: ‘CURLINFO_CONTENT_LENGTH_DOWNLOAD’ is deprecated: since 7.55.0. Use CURLINFO_CONTENT_LENGTH_DOWNLOAD_T [-Werror=deprecated-declarations]
|  1158 |           if (curl_easy_getinfo(target_handle, CURLINFO_CONTENT_LENGTH_DOWNLOAD,
|       |           ^~
| /home/gemac/test/build-torizon/tmp/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include/curl/curl.h:2892:3: note: declared here
|  2892 |   CURLINFO_CONTENT_LENGTH_DOWNLOAD
|       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| cc1: all warnings being treated as errors
| make[2]: *** [Makefile:629: debuginfod-client.o] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[1]: *** [Makefile:525: all-recursive] Error 1
| make: *** [Makefile:441: all] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
ERROR: Task (virtual:native:/home/gemac/test/build-torizon/conf/../../layers/openembedded-core/meta/recipes-devtools/elfutils/elfutils_0.186.bb:do_compile) failed with exit code '1'

When using the tdxref manifest the recipe compiles without problems.

Best regards,

Markus

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I understand you’re experiencing a compilation error with the elfutils recipe when using the torizoncore manifest in BSP 6.8.5. The error indicates a deprecated CURL function is being used, which causes compilation to fail when warnings are treated as errors.

Understanding the Manifest Differences

The Toradex manifests serve different purposes (1):

  • torizoncore manifest: Used for building Torizon and Torizon Reference Images (1)
  • tdxref manifest: Used for building Reference Images with the BSP (1)

Each manifest contains different layer configurations and potentially different versions of upstream components, which can explain why the same recipe behaves differently between manifests.

Recommended Solutions

1. Use the tdxref Manifest

Since you confirmed that the tdxref manifest compiles successfully, this would be the most straightforward approach if it meets your project requirements (1).

2. Create a Custom Layer with a Fix

If you need to use the torizoncore manifest specifically, you can create a custom meta layer to patch the elfutils recipe (2):

mkdir -p meta-custom/recipes-devtools/elfutils

(2)

Then create a .bbappend file to apply a patch that addresses the deprecated CURL function usage (2).

3. Check for Updates

Consider checking if there are newer BSP releases that might have resolved this issue, as this appears to be an upstream compatibility problem with newer CURL versions.

Additional Context

When working with custom layers in Torizon OS, remember that all custom layers must be version controlled by Git due to how layer revision information is included with OSTree (2). If you create a custom fix, ensure your layer is properly initialized as a Git repository (2).

The difference in behavior between manifests suggests this is a known issue that has been addressed in the reference image builds but not yet in the Torizon-specific builds for this BSP version.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @Mowlwurf,

This looks similar to a rare issue that has been brought up before. One solution is to apply a patch on the elfutils recipe from upstream as described here: Yocto CROPS 6.x build fails on elfutils - #6 by drew.tx

One question though since this issue seems to be environment dependent and not 100% reproducible between everyone. Are you doing this Yocto build in a container like CROPS, or are you building this natively on your machine? And, if you are building it natively on your machine what Linux distribution are you building it on?

Best Regards,
Jeremias

4

Hello @jeremias.tx,

thank you for your fast response.

I’m working with Ubuntu under WSLv2 for several years now without problems. However, I recently upgraded the distribution from 22.04LTS to 24.04LTS because Yocto Kirkstone supports it, and now the problem with elfutils has occurred.

I will try the patch you suggested.

Best regards,

Markus

5

I added the following file to my custom layer to make it work:

$ cat recipes-devtools/elfutils/elfutils_0.186.bbappend
# patch for building with Torizon 6.8.x on Ubuntu 24.04
CFLAGS:append = " -Wno-error=deprecated-declarations"

Now I’m wondering why the operating system version of my build computer affects whether this package is successfully built.

Best regards,

Markus Dost

6

However, I recently upgraded the distribution from 22.04LTS to 24.04LTS because Yocto Kirkstone supports it, and now the problem with elfutils has occurred.

That’s strange, the few cases I’ve seen before of this usually the user was on some not-supported Linux distro. But that doesn’t appear to be the case for you. Furthermore, the build worked prior on 22.04 for you, as I understand. So somehow upgrading to 24.04 (still a supported distro), broke the build for you.

Now I’m wondering why the operating system version of my build computer affects whether this package is successfully built.

That’s hard to say for sure exactly. Yocto does have some reliance on the underlying host system. Though with how complex Yocto can be at times, it’s hard to tell what exactly influences the build.

At least you found a fix for your setup that works. Personally I do builds in Yocto containers to have a controlled consistent environment, to avoid such strange behaviors like this.

Best Regards,
Jeremias