On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus <hans.becke...@gmail.com> wrote: > On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus <hans.becke...@gmail.com> > wrote: >> 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 :( >> >> > Ok. I have done some further tests now and my conclusion is that > something is definitely broken in the way the toolchain is prepared. > The references to /opt/... in the case above comes due to having the > default SDKPATH as set by meta-yocto/conf/distro/poky.conf. Fine. I > then changed our distro to override SDKPATH to point to the actual > path for which we install the SDK and rebuilt. About an hour later I > tried it out just to find that it is still not handling libtool things > properly :( I still have to force the use of --with-libtool-sysroot > when configuring packages to make the build stage pass without errors! > Can someone confirm if this is a bug in libtool, in the way Yocto sets > it up, or if I am doing something wrong? As a workaround I guess it is > possible to always do "./configure $CONFIGURE_FLAGS <other options>", > but surely, this can not be how it was supposed to work? > > Thanks. > Hans > > First of all. I am really sorry for spamming this forum and this subject. But I really need to sort this out and I have some new information I would like to share. I believe I have found the root cause of the problem, at least the one that we have with improper resolution of .la files. In the generated '<host-target>-libtool' file the variable 'lt_sysroot' remains unset unless --with-libtool-sysroot is set to something! That I believe is the bug! It should in the case of omitting --with-libtool-sysroot be set to the output from e.g. 'gcc --print-sysroot'! Or maybe more correctly:
if test "$GCC" = yes; then lt_sysroot=`$CC --print-sysroot 2>/dev/null` fi Also, I now discovered the purpose of prefixing dependency paths in .la files with '=' ;) It is used to flag the libtool script to replace = with $lt_sysroot. Never seen that before ;) Someone that can comment on this? Is this a know bug in our running version of Yocto? Any clues how this could be fixed otherwise? What is generating the actual libtool script? 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-20130904" TUNE_FEATURES = "armv7a vfp cortexa9" TARGET_FPU = "vfp" meta meta-yocto meta-yocto-bsp = "master:0c0bb02f5104e3856c9d90088e1ece08652cc19f" meta-oe = "master:7c292ce28756824b1fa377d516aedd979fa41f19" Thanks. Hans >>>>> 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