Bug-fixes for building of Ångström v2017.12 Toradex-2.8b7 on Ubuntu-20.04

During update of Ångström v2017.12 from Toradex-2.8b3 to Toradex-2.8b7 I have noticed various issues on Ubuntu-20.04 build host.

  1. glib-2.0 build process fails with errors “‘%s’ directive argument is null”. Use patch 1 to fix it.
  2. elfutils_0.170 build process fails with error “__elf32_msize’ specifies less restrictive attribute than its target ‘elf32_fsize’”. Use patch 2 to fix it.
  3. qemu_2.10.0 build process fails with error “static declaration of ‘gettid’ follows non-static declaration”. Use patch 3 to fix it.
  4. libgpg-error_1.27 build process fails with error “gawk: fatal: cannot use gawk builtin `namespace’ as variable name”. Use patch 4 to fix it.

Greetings @plyatov!

Thank you for your report and for the patches.

How did you upgrade from BSP 2.8b3 to 2.8b7?

Are you able to reproduce this on a new, clean environment?

Dear Gustavo,

Originally, BSP 2.8b3 was built on Ubuntu-18.04.

Then I have:

  • Upgrade Ubuntu to 20.04
  • Make BSP repo sync to obtain 2.8b7
  • Trying to rebuild console-tdx-image
  • Got issues reported above.

Now, I have removed content of build and deploy directories and run building of console-tdx-image again. Got issues reported below.

m4-native-1.4.18

freadahead.c: error: #error “Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib.”

Use patch 5 to fix it.

cross-localedef-native_2.26

argp-fmtstream.o: in function _argp_fmtstream_update': | argp-fmtstream.c:(.text+0x4da): undefined reference to _IO_fwide’

Use patch 6 to fix it.

bison-3.0.4

lib/fseterr.c:77:3: error: #error “Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib.”

Use patch 7 to fix it.

Please note that Ubuntu 20.04 is not really an approved distribution to build such older OpenEmbedded Rocko resp. Yocto Project 2.4 based images. Rather then such attempted fixing one could easily build it in an approved container of choice.

Dear @marcel.tx,
I don’t see a reason to use container when support for native OS can be easily added.

Then please do so but don’t expect others to follow suit. Thanks!