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
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto