Failed to crosscompile x11-libs/pixman-0.18.0 on amd64 for arm. There is try to build testsuite, but it cannot suceed (because is build for host but with guest CFLAGS). Test suite should not be build at all when cross-compiling. Reproducible: Always Actual Results: CC a1-trap-test.o CCLD a1-trap-test ../pixman/.libs/libpixman-1.so: undefined reference to `__tls_get_addr' collect2: ld returned 1 exit status make[2]: *** [a1-trap-test] Error 1 make[2]: Leaving directory `/usr/arm-softfloat-linux-uclibcgnueabi/tmp/portage/x11-libs/pixman-0.18.0/work/pixman-0.18.0/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/arm-softfloat-linux-uclibcgnueabi/tmp/portage/x11-libs/pixman-0.18.0/work/pixman-0.18.0' make: *** [all] Error 2 build for x11-libs/pixman-0.17* works fine because for testsuite does not pass GUEST CFLAGS to compiler/linker.
Could you please paste "arm-softfloat-linux-uclibcgnueabi-gcc -v" output?
OK, reproduced somewhat similar myself. This toolchain seems to have broken with the regards to '__thread' support: # arm-softfloat-linux-uclibcgnueabi-gcc -v Using built-in specs. Target: arm-softfloat-linux-uclibcgnueabi Configured with: /var/tmp/cross/arm-softfloat-linux-uclibcgnueabi/portage/cross-arm-softfloat-linux-uclibcgnueabi/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/powerpc64-unknown-linux-gnu/arm-softfloat-linux-uclibcgnueabi/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/arm-softfloat-linux-uclibcgnueabi/4.3.4/include --datadir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.3.4 --mandir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.3.4/man --infodir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/arm-softfloat-linux-uclibcgnueabi/4.3.4/include/g++-v4 --host=powerpc64-unknown-linux-gnu --target=arm-softfloat-linux-uclibcgnueabi --build=powerpc64-unknown-linux-gnu --enable-altivec --disable-fixed-point --with-float=soft --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --disable-libgcj --enable-languages=c,c++,fortran --with-sysroot=/usr/arm-softfloat-linux-uclibcgnueabi --disable-bootstrap --disable-libgomp --disable-__cxa_atexit --enable-target-optspace --enable-tls --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.1, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) /**************/ int __thread a; int main() { return a; } /**************/ # arm-softfloat-linux-uclibcgnueabi-gcc test.c /tmp/cc8Ju5Xm.o: In function `main': test.c:(.text+0xc): undefined reference to `__aeabi_read_tp' collect2: ld returned 1 exit status And this might be your problem: http://patchwork.openembedded.org/patch/907/
# arm-softfloat-linux-uclibcgnueabi-gcc -v Using built-in specs. Target: arm-softfloat-linux-uclibcgnueabi Configured with: /tmp/cross/arm-softfloat-linux-uclibcgnueabi/portage/cross-arm-softfloat-linux-uclibcgnueabi/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-softfloat-linux-uclibcgnueabi/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/arm-softfloat-linux-uclibcgnueabi/4.4.3/include --datadir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.4.3 --mandir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.4.3/man --infodir=/usr/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/arm-softfloat-linux-uclibcgnueabi/4.4.3/include/g++-v4 --host=x86_64-pc-linux-gnu --target=arm-softfloat-linux-uclibcgnueabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --with-float=soft --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/arm-softfloat-linux-uclibcgnueabi/4.4.3/python --disable-libgcj --enable-languages=c,c++ --with-sysroot=/usr/arm-softfloat-linux-uclibcgnueabi --disable-bootstrap --disable-libgomp --disable-__cxa_atexit --enable-target-optspace --enable-tls --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3-r2 p1.2' Thread model: posix gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)
Can you try disabling tls support in your toolchain just like openembedded guys do? pixman 0.18.0 requires either non-broken '__thread' support or no support for '__thread' at all. Please note that pixman 0.18.0 has some bugs with the alretnative pthread based solution (it is used when '__thread' is not available). These bugs are supposed to be fixed in the soon to be released 0.18.2 update, but for now pixman git may be the best choice.
If anybody would consider my opinion, this bug belongs to toolchain.
@toolchain, looks like gcc's ARM support is somewhat broken? Could you guys confirm? I haven't looked at pixman yet, but maybe we should make tls support build-time configurable? Thanks
you shouldnt require tls in packages as it wont work on uClibc systems. use the tc-has-tls function from toolchain-funcs.eclass.
(In reply to comment #7) > you shouldnt require tls in packages as it wont work on uClibc systems. The question is why 'arm-softfloat-linux-uclibcgnueabi' toolchain built by crossdev includes '--with-tls' option (see the information from comment 2) even though tls is not supposed to work on uClibc systems? > use the tc-has-tls function from toolchain-funcs.eclass. But this tc-has-tls function from toolchain-funcs.eclass is gentoo specific, right? Upstream pixman configure script checks for tls support availability by trying to compile a small chunk of code similar to the one from comment 2. Such check does not provide expected results in gentoo because the compilation succeeds but the failure happens at the linking stage. Is this supposed to be normal?
This should not be a problem with pixman-0.20.0 and newer because now pixman configure script tries to both compile and *link* all tests. Nevertheless, there's still a problem with __thread support detection (it is never detected because of another bug). The fix is on its way.
Really looks working with the stable we have now. Please reopen if problem still occurs at your machines.
