[yocto] libtool problem?

[Hans Beckérus]

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 :(


>>> Jay
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto