[yocto] libtool problem?

Hans Beckérus hans.beckerus at gmail.com
Thu Sep 5 00:40:59 PDT 2013 

On Wed, Sep 4, 2013 at 6:06 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>> On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>> On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>>> On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>>>> On Wed, Sep 4, 2013 at 11:36 AM, JC <jc at 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.beckerus at 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 at yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto

More information about the yocto mailing list