On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus <hans.becke...@gmail.com> wrote: > On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.becke...@gmail.com> > wrote: >> On Wed, Sep 4, 2013 at 11:36 AM, JC <j...@vtkloud.com> wrote: >>> On 04/09/2013 11:24, Hans Beckérus wrote: >>>> >>>> On Wed, Sep 4, 2013 at 9:53 AM, Hans Beckérus <hans.becke...@gmail.com> >>>> wrote: >>>>> >>>>> Hi. I recently discovered that our populated SDK can not properly >>>>> build much at all :( >>>>> libtool complains about .la files that have been moved and not being >>>>> able to find dito. >>>>> The rootfs builds fine however. What I did noticed was that in our .la >>>>> files we get lines like this: >>>>> >>>>> dependency_libs=' =/usr/lib/libxcb.la =/usr/lib/libXau.la >>>>> =/usr/lib/libXdmcp.la' >>>>> >>>>> Is that '='-sign really supposed to be there? Is that why many builds >>>>> fails to properly locate the .la files? >>>>> >>>> The '='-sign is still a mystery to me. But it does not seem to matter >>>> much. >>>> If I configure my packages (built from the SDK toolchain) using >>>> >>>> '--with-libtool-sysroot=/home/toolchain/sysroots/cortexa9-vfp-poky-linux-gnueabi/' >>>> it works! But should that really be needed? Is the path to be used by >>>> libtool not supposed to be automatically resolved to point at the >>>> toolchain sysroot in cross-compilation environment? >>> >>> >>> In my case '--with-libtool-sysroot' is correctly resolved by the SDK setup, >>> but ./configure complains it does not recognize it, so I end up not being >>> able to test generated (dynamically linked) binaries. The common "hello >>> world" template says it cannot find ld-linux, and indeed it's in the path of >>> libtool-sysroot. >>> >>> Googling it did not helped me to resolve the issue :( >>> >> Yes, in my case the script sourced also resolves the path correct to >> CONFIGURE_FLAGS, but that is not automatically used by a generated >> configure script is it!? I guess that is why I need to add it manually >> each time. You should not to do that, or? >> > According to generated 'configure' the option should not be needed. > > --with-libtool-sysroot=DIR Search for dependent libraries within DIR > (or the compiler's sysroot if not specified). > > So, if --with-libtool-sysroot is not set it should pick it up from > whatever the compiler is using. > That does not seem to work :( > Ah. Is not the problem here that the cross-compiler is broken?
Configured with: /home/poky/build/tmp/work-shared/gcc-4.7.2-r20/gcc-4.7.2/configure --build=x86_64-linux --host=x86_64-pokysdk-linux --target=arm-poky-linux-gnueabi --prefix=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr --exec_prefix=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr --bindir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/cortexa9-vfp-poky-linux-gnueabi --sbindir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/cortexa9-vfp-poky-linux-gnueabi --libexecdir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/libexec/cortexa9-vfp-poky-linux-gnueabi --datadir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/share --sysconfdir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/etc --sharedstatedir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/com --localstatedir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/var --libdir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/cortexa9-vfp-poky-linux-gnueabi --includedir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/include --oldincludedir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/include --infodir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/info --mandir=/opt/poky-chris/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/opt/poky-chris/1.4+snapshot/sysroots/cortexa9-vfp-poky-linux-gnueabi/usr/include/c++ --with-build-time-tools=/home/poky/build/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin --with-sysroot=/opt/poky-chris/1.4+snapshot/sysroots/cortexa9-vfp-poky-linux-gnueabi --with-build-sysroot=/home/poky/build/tmp/sysroots/zynq-zc706 --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap --with-mpfr=/home/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-mpc=/home/poky/build/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --enable-nls There are several hardcoded paths to /opt/...!? That is not where my toolchain is installed I am afraid :( Have I done something wrong in my configuration that is causing populate_sdk to produce a broken toolchain like this? Also, there are several 'sysroots' pointed to. And one of those is my actual Yocto build location? This looks really messed up :( >>> Jay >>> >>> _______________________________________________ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto