[yocto] Problems building util-linux when wide character support is disabled in distro

[Hans Beckerus]

On 2013-09-17 5:09, Hans Beckérus wrote:
> Hi. We are having som problems building our rootfs now that our custom
> distro (based on poky-tiny) no longer includes wide character support
> in libc.
> Here is an example of the errors we get:
>
> | arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-gcc
> -march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mtune=cortex-a9
> --sysroot=/home/qhanbec/poky/build/tmp/sysroots/zynq-zc706 -std=gnu99
> -fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra
> -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes
> -Wno-missing-field-initializers -Wredundant-decls -Wsign-compare
> -Wtype-limits -Wuninitialized -Wunused-but-set-parameter
> -Wunused-but-set-variable -Wunused-parameter -Wunused-result
> -Wunused-variable -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed -o ul text-utils/ul.o  -ltinfo
> | text-utils/rev.o: In function `main':
> | /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:139:
> undefined reference to `fgetws'
> | /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:151:
> undefined reference to `fgetws'
> | /home//poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:154:
> undefined reference to `wcslen'
> | /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:160:
> undefined reference to `putwchar'
> | /home/poky/build/tmp/work/cortexa9-vfp-poky-linux-gnueabi/util-linux/2.22.2-r3/util-linux-2.22.2/text-utils/rev.c:162:
> undefined reference to `putwchar'
> | collect2: error: ld returned 1 exit status
>
> The problem is that util-linux still thinks we have wide character
> support (from configure.ac):
>
> AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
> #include <wchar.h>
> #include <wctype.h>
> #include <stdio.h>
> ]], [[
>   wchar_t wc;
>   wint_t w;
>   w = fgetwc(stdin);
>   if (w == WEOF) exit(1);
>   wc = w;
>   fputwc(wc,stdout);
> ]])],
> [AC_DEFINE(HAVE_WIDECHAR,1,Do we have wide character support?)
> ])
>
> Since no linking is performed due to x-compilation, all that this does
> is basically checking if wchar.h exists or not.
Actually, I think what is missing here is a AC_TRY_LINK.
But it does not seem to matter much. There are also numerous of places in the util-linux code that are
completely missing out on checks if wide character support is available or not.
The way forward as I can see right now is to revert and put back the wide character support in libc.
Unless I can figure out why util-linux is actually being built in the first place? What can cause dependencies to this
package? It is not part of our IMAGE_FEATURES directly, nor indirectly and is not installed in our rootfs.
But something requires it. Any hints on how to trace this back?
 
> And that is also were the problem is. Even if we have disabled wide
> character support in eglibc, the wchar.h header files is still copied
> to our sysroot!?
> Is that really how it should be when DISTRO_FEATURES_LIBC does not
> include 'libc-posix-clang-wchar libc-posix-wchar-io'?
> Here is our DISTRO_FEATURES (as reported by bitbake -e) and build environment:
>
> DISTRO_FEATURES="ipv4 usbhost usbgadget ${DISTRO_FEATURES_WIFI}
> libc-libm libc-crypt libc-utmp libc-getlogin libc-posix-regexp
> libc-inet libc-nis   sysvinit largefile nfs"
>
> Build Configuration:
> BB_VERSION        = "1.19.0"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "SUSE-LINUX-11"
> TARGET_SYS        = "arm-poky-linux-gnueabi"
> MACHINE           = "zynq-zc706"
> DISTRO            = "poky-chris"
> DISTRO_VERSION    = "1.4+snapshot-20130917"
> TUNE_FEATURES     = "armv7a vfp cortexa9"
> TARGET_FPU        = "vfp"
> meta
> meta-yocto
> meta-yocto-bsp    = "master:3b38c898a4647c6a639d0dbd416b0bbacbf278f5"
> meta-oe           = "master:7c292ce28756824b1fa377d516aedd979fa41f19"
>
> Any ideas how what might be wrong here?
>
> Thanks.
> Hans