On Wed, Sep 4, 2013 at 6:06 PM, Hans Beckérus <hans.becke...@gmail.com> wrote: > 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 > Ok, the problem is in the generated configure script! I saw Khem had a patch in Yocto to change --with-sysroot to --with-libtool-sysroot, but there is one more error in the code below
lt_sysroot= case ${with_libtool_sysroot} in #( yes) if test "$GCC" = yes; then lt_sysroot=`$CC --print-sysroot 2>/dev/null` fi ;; #( /*) lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"` ;; #( no|'') ;; #( *) { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${with_libtool_sysroot}" >&5 $as_echo "${with_libtool_sysroot}" >&6; } as_fn_error $? "The sysroot must be an absolute path." "$LINENO" 5 ;; esac The yes) and no) switch cases should be swapped! Now if -with-libtool-sysroot=yes it will pick up lt_sysroot from the compiler! And not vice versa! This is definitely wrong. Please advice. Is this something that can be fixed in the scope of Yocto or must a solution to this come from autotools? Can I patch this somehow in Yocto? The patch I guess must be in the code that generates the configure script. 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