[yocto] libtool problem?
Hans Beckérus
hans.beckerus at gmail.com
Wed Sep 4 09:06:58 PDT 2013
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
>>>>> Jay
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto at yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
More information about the yocto
mailing list