libtool problem?

libtool problem?

[Hans Beckérus]

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?

Thanks.
Hans

Re: libtool problem?

[Hans Beckérus]

On Wed, Sep 4, 2013 at 9:53 AM, Hans Beckérus <hans.beckerus@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?

> Thanks.
> Hans

Re: libtool problem?

[JC]

On 04/09/2013 11:24, Hans Beckérus wrote:
> On Wed, Sep 4, 2013 at 9:53 AM, Hans Beckérus <hans.beckerus@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 :(

Jay

Re: libtool problem?

[Hans Beckérus]

On Wed, Sep 4, 2013 at 11:36 AM, JC <jc@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@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?

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

Re: libtool problem?

[Hans Beckérus]

On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 11:36 AM, JC <jc@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@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 :(

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

Re: libtool problem?

[Hans Beckérus]

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

Re: libtool problem?

[Hans Beckérus]

On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>> On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>> On Wed, Sep 4, 2013 at 11:36 AM, JC <jc@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@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


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

Re: libtool problem?

[Hans Beckérus]

On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>> On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>> On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>>> On Wed, Sep 4, 2013 at 11:36 AM, JC <jc@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@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

Re: libtool problem?

[Hans Beckérus]

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

Re: libtool problem?

[Hans Beckérus]

On Thu, Sep 5, 2013 at 9:40 AM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 6:06 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>> On Wed, Sep 4, 2013 at 5:02 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>> On Wed, Sep 4, 2013 at 12:21 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>>> On Wed, Sep 4, 2013 at 12:03 PM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>>>> On Wed, Sep 4, 2013 at 11:56 AM, Hans Beckérus <hans.beckerus@gmail.com> wrote:
>>>>>> On Wed, Sep 4, 2013 at 11:36 AM, JC <jc@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@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
>
>

I have now prepared a patch that will fix this problem i Yocto. Since
no one (so far) commented on this issue I interpreted the silence as
that nothing has been done about this bug. But I am very surprised, to
say the least, that this problem has passed unnoticed!
The patch goes into meta/recipes-development/libtool/libtool. This
patch *must* be applied after Khems patch that renames --with-sysroot
to --with-libtool-sysroot (rename-with-sysroot.patch).
After applying the patch (and added it to libtool-2.4.2.inc) the
populated SDK toolchain works as expected also when
--with-libtool-sysroot is not provided, instead it is picked up from
$CC --print-sysroot. I have filed a bug report to bug-libtool since
the real problem is in libtool itself, not Yocto.

Thanks.
Hans

---

diff -ur libtool-2.4.2.orig/configure libtool-2.4.2/configure
--- libtool-2.4.2.orig/configure 2013-09-05 10:37:50.982677000 +0200
+++ libtool-2.4.2/configure 2013-09-05 10:12:24.551681000 +0200
@@ -6814,7 +6814,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -6822,7 +6822,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/libltdl/configure libtool-2.4.2/libltdl/configure
--- libtool-2.4.2.orig/libltdl/configure 2013-09-05 10:37:24.738048000 +0200
+++ libtool-2.4.2/libltdl/configure 2013-09-05 10:38:44.540026000 +0200
@@ -6027,7 +6027,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -6035,7 +6035,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/libltdl/m4/libtool.m4
libtool-2.4.2/libltdl/m4/libtool.m4
--- libtool-2.4.2.orig/libltdl/m4/libtool.m4 2013-09-05 10:37:24.690013000 +0200
+++ libtool-2.4.2/libltdl/m4/libtool.m4 2013-09-05 12:05:51.560281000 +0200
@@ -1234,7 +1234,7 @@
 dnl in case the user passed a directory name.
 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -1242,7 +1242,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    AC_MSG_RESULT([${with_libtool_sysroot}])
diff -ur libtool-2.4.2.orig/tests/cdemo/configure
libtool-2.4.2/tests/cdemo/configure
--- libtool-2.4.2.orig/tests/cdemo/configure 2013-09-05 10:37:24.793021000 +0200
+++ libtool-2.4.2/tests/cdemo/configure 2013-09-05 10:39:01.039463000 +0200
@@ -5907,7 +5907,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5915,7 +5915,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/demo/configure
libtool-2.4.2/tests/demo/configure
--- libtool-2.4.2.orig/tests/demo/configure 2013-09-05 10:37:24.878048000 +0200
+++ libtool-2.4.2/tests/demo/configure 2013-09-05 10:39:15.357833000 +0200
@@ -5905,7 +5905,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5913,7 +5913,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/depdemo/configure
libtool-2.4.2/tests/depdemo/configure
--- libtool-2.4.2.orig/tests/depdemo/configure 2013-09-05
10:37:25.003086000 +0200
+++ libtool-2.4.2/tests/depdemo/configure 2013-09-05 10:39:33.424217000 +0200
@@ -5902,7 +5902,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5910,7 +5910,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/f77demo/configure
libtool-2.4.2/tests/f77demo/configure
--- libtool-2.4.2.orig/tests/f77demo/configure 2013-09-05
10:37:25.232029000 +0200
+++ libtool-2.4.2/tests/f77demo/configure 2013-09-05 12:02:54.749911000 +0200
@@ -6887,7 +6887,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -6895,7 +6895,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/fcdemo/configure
libtool-2.4.2/tests/fcdemo/configure
--- libtool-2.4.2.orig/tests/fcdemo/configure 2013-09-05
10:37:25.320032000 +0200
+++ libtool-2.4.2/tests/fcdemo/configure 2013-09-05 12:03:34.350859000 +0200
@@ -6986,7 +6986,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -6994,7 +6994,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/mdemo/configure
libtool-2.4.2/tests/mdemo/configure
--- libtool-2.4.2.orig/tests/mdemo/configure 2013-09-05 10:37:25.458028000 +0200
+++ libtool-2.4.2/tests/mdemo/configure 2013-09-05 12:04:04.233622000 +0200
@@ -5934,7 +5934,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5942,7 +5942,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/mdemo2/configure
libtool-2.4.2/tests/mdemo2/configure
--- libtool-2.4.2.orig/tests/mdemo2/configure 2013-09-05
10:37:25.564096000 +0200
+++ libtool-2.4.2/tests/mdemo2/configure 2013-09-05 12:04:36.688447000 +0200
@@ -5907,7 +5907,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5915,7 +5915,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/pdemo/configure
libtool-2.4.2/tests/pdemo/configure
--- libtool-2.4.2.orig/tests/pdemo/configure 2013-09-05 10:37:25.619085000 +0200
+++ libtool-2.4.2/tests/pdemo/configure 2013-09-05 12:04:50.578801000 +0200
@@ -5910,7 +5910,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -5918,7 +5918,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5
diff -ur libtool-2.4.2.orig/tests/tagdemo/configure
libtool-2.4.2/tests/tagdemo/configure
--- libtool-2.4.2.orig/tests/tagdemo/configure 2013-09-05
10:37:25.727040000 +0200
+++ libtool-2.4.2/tests/tagdemo/configure 2013-09-05 12:05:11.896353000 +0200
@@ -6926,7 +6926,7 @@

 lt_sysroot=
 case ${with_libtool_sysroot} in #(
- yes)
+ no)
    if test "$GCC" = yes; then
      lt_sysroot=`$CC --print-sysroot 2>/dev/null`
    fi
@@ -6934,7 +6934,7 @@
  /*)
    lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
    ;; #(
- no|'')
+ yes|'')
    ;; #(
  *)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result:
${with_libtool_sysroot}" >&5


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

Re: libtool problem?

[Richard Purdie]

On Thu, 2013-09-05 at 17:44 +0200, Hans Beckérus wrote:
> I have now prepared a patch that will fix this problem i Yocto. Since
> no one (so far) commented on this issue I interpreted the silence as
> that nothing has been done about this bug. 

I think that coming up to release, we've all be focusing on that. Once
you'd identified a specific issue like this, filing a bug report in the
bugzilla can be a good way of getting people's attention, particularly
when you have a patch.

The key question is the help message:

 --with-libtool-sysroot=DIR Search for dependent libraries within DIR
                       (or the compiler's sysroot if not specified).

so yes, this sounds like a genuine bug in libtool. Would you like to
send a patch to the OE-Core mailing list which adds your patch, along
with a description of the problem in the commit messages, a proper patch
header (description and Upstream-Status:) and signed-off-by line?

If you do, I think we'll likely include it. If not, it will need to wait
for someone to turn this into a full commit which might take a little
longer but it does look like a good change.

Cheers,

Richard



> But I am very surprised, to
> say the least, that this problem has passed unnoticed!
> The patch goes into meta/recipes-development/libtool/libtool. This
> patch *must* be applied after Khems patch that renames --with-sysroot
> to --with-libtool-sysroot (rename-with-sysroot.patch).
> After applying the patch (and added it to libtool-2.4.2.inc) the
> populated SDK toolchain works as expected also when
> --with-libtool-sysroot is not provided, instead it is picked up from
> $CC --print-sysroot. I have filed a bug report to bug-libtool since
> the real problem is in libtool itself, not Yocto.

Re: libtool problem?

[Hans Beckérus]

On Fri, Sep 6, 2013 at 10:25 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2013-09-05 at 17:44 +0200, Hans Beckérus wrote:
>> I have now prepared a patch that will fix this problem i Yocto. Since
>> no one (so far) commented on this issue I interpreted the silence as
>> that nothing has been done about this bug.
>
> I think that coming up to release, we've all be focusing on that. Once
> you'd identified a specific issue like this, filing a bug report in the
> bugzilla can be a good way of getting people's attention, particularly
> when you have a patch.
>
> The key question is the help message:
>
>  --with-libtool-sysroot=DIR Search for dependent libraries within DIR
>                        (or the compiler's sysroot if not specified).
>
> so yes, this sounds like a genuine bug in libtool. Would you like to
> send a patch to the OE-Core mailing list which adds your patch, along
> with a description of the problem in the commit messages, a proper patch
> header (description and Upstream-Status:) and signed-off-by line?
>
> If you do, I think we'll likely include it. If not, it will need to wait
> for someone to turn this into a full commit which might take a little
> longer but it does look like a good change.
>
Hi Richard, I am fully aware that people are currently on their toes
for the upcoming release.
I did not mean to sound harsh, if that was how it came out, I am truly
sorry. It is just that I am used to quick feedback :) and since I
heard nothing I though maybe this problem is to specific for anyone to
actually comment on it. As I said, this is really a bug in libtool so
the best solution would of course be an upstream fix. But I needed a
solution to this much quicker than that. I am not really expecting
Yocto to fix a libtool problem. I only wished to flag for the problem
and provide the patch if more people stumble into the same issue. And
sure, I can try to post this patch in a proper way. I will probably
mess it up, but there is a first time for everything ;) Is there some
document that describes the exact procedure for sending a patch for
review in Yocto? I guess you also wish to have some ticket id or
something to connect it to?
As it stands right now we have a .bbappend to workaround this so there
is really no panic.

Thanks.
Hans








> Cheers,
>
> Richard
>
>
>
>> But I am very surprised, to
>> say the least, that this problem has passed unnoticed!
>> The patch goes into meta/recipes-development/libtool/libtool. This
>> patch *must* be applied after Khems patch that renames --with-sysroot
>> to --with-libtool-sysroot (rename-with-sysroot.patch).
>> After applying the patch (and added it to libtool-2.4.2.inc) the
>> populated SDK toolchain works as expected also when
>> --with-libtool-sysroot is not provided, instead it is picked up from
>> $CC --print-sysroot. I have filed a bug report to bug-libtool since
>> the real problem is in libtool itself, not Yocto.
>
>
>

Re: libtool problem?

[Richard Purdie]

On Fri, 2013-09-06 at 10:59 +0200, Hans Beckérus wrote:
> On Fri, Sep 6, 2013 at 10:25 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2013-09-05 at 17:44 +0200, Hans Beckérus wrote:
> >> I have now prepared a patch that will fix this problem i Yocto. Since
> >> no one (so far) commented on this issue I interpreted the silence as
> >> that nothing has been done about this bug.
> >
> > I think that coming up to release, we've all be focusing on that. Once
> > you'd identified a specific issue like this, filing a bug report in the
> > bugzilla can be a good way of getting people's attention, particularly
> > when you have a patch.
> >
> > The key question is the help message:
> >
> >  --with-libtool-sysroot=DIR Search for dependent libraries within DIR
> >                        (or the compiler's sysroot if not specified).
> >
> > so yes, this sounds like a genuine bug in libtool. Would you like to
> > send a patch to the OE-Core mailing list which adds your patch, along
> > with a description of the problem in the commit messages, a proper patch
> > header (description and Upstream-Status:) and signed-off-by line?
> >
> > If you do, I think we'll likely include it. If not, it will need to wait
> > for someone to turn this into a full commit which might take a little
> > longer but it does look like a good change.
> >
> Hi Richard, I am fully aware that people are currently on their toes
> for the upcoming release.
> I did not mean to sound harsh, if that was how it came out, I am truly
> sorry. It is just that I am used to quick feedback :) and since I
> heard nothing I though maybe this problem is to specific for anyone to
> actually comment on it.

It wasn't harsh, I just want to make sure you know you're not being
ignored, fixes for issues like this are much appreciated and key to
improving the project. Equally, there aren't enough hours in the day for
us to do everything, we try our best! :)

>  As I said, this is really a bug in libtool so
> the best solution would of course be an upstream fix.

Agreed, however I know first hand how hard it is to get fixes into
libtool. So we're prepared to put this one with the other libtool fixes
we have.

>  But I needed a
> solution to this much quicker than that. I am not really expecting
> Yocto to fix a libtool problem. I only wished to flag for the problem
> and provide the patch if more people stumble into the same issue. And
> sure, I can try to post this patch in a proper way. I will probably
> mess it up, but there is a first time for everything ;)

Indeed, the first time you do this its quite daunting but equally, we'll
do our best to help you through it and its not actually so bad. I'm
suggesting you do go through the process since if you then later have
other changes, you'll be more likely to submit them too and I would
encourage people to do that.

>  Is there some
> document that describes the exact procedure for sending a patch for
> review in Yocto?

http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#how-to-submit-a-change

Don't worry about maintainers and so on for this one, just send it to
the OE-Core list.

>  I guess you also wish to have some ticket id or
> something to connect it to?

Its not essential in a case like this where the issue is now well
understood.

> As it stands right now we have a .bbappend to workaround this so there
> is really no panic.

If its going to be in the release which I'd like it to be, I could do
with it sooner than later though. If you don't have the time, fair
enough but it does seem like a good fix.

Cheers,

Richard

Re: libtool problem?

[Hans Beckérus]

On Fri, Sep 6, 2013 at 11:53 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2013-09-06 at 10:59 +0200, Hans Beckérus wrote:
>> On Fri, Sep 6, 2013 at 10:25 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> > On Thu, 2013-09-05 at 17:44 +0200, Hans Beckérus wrote:
>> >> I have now prepared a patch that will fix this problem i Yocto. Since
>> >> no one (so far) commented on this issue I interpreted the silence as
>> >> that nothing has been done about this bug.
>> >
>> > I think that coming up to release, we've all be focusing on that. Once
>> > you'd identified a specific issue like this, filing a bug report in the
>> > bugzilla can be a good way of getting people's attention, particularly
>> > when you have a patch.
>> >
>> > The key question is the help message:
>> >
>> >  --with-libtool-sysroot=DIR Search for dependent libraries within DIR
>> >                        (or the compiler's sysroot if not specified).
>> >
>> > so yes, this sounds like a genuine bug in libtool. Would you like to
>> > send a patch to the OE-Core mailing list which adds your patch, along
>> > with a description of the problem in the commit messages, a proper patch
>> > header (description and Upstream-Status:) and signed-off-by line?
>> >
>> > If you do, I think we'll likely include it. If not, it will need to wait
>> > for someone to turn this into a full commit which might take a little
>> > longer but it does look like a good change.
>> >
>> Hi Richard, I am fully aware that people are currently on their toes
>> for the upcoming release.
>> I did not mean to sound harsh, if that was how it came out, I am truly
>> sorry. It is just that I am used to quick feedback :) and since I
>> heard nothing I though maybe this problem is to specific for anyone to
>> actually comment on it.
>
> It wasn't harsh, I just want to make sure you know you're not being
> ignored, fixes for issues like this are much appreciated and key to
> improving the project. Equally, there aren't enough hours in the day for
> us to do everything, we try our best! :)
>
>>  As I said, this is really a bug in libtool so
>> the best solution would of course be an upstream fix.
>
> Agreed, however I know first hand how hard it is to get fixes into
> libtool. So we're prepared to put this one with the other libtool fixes
> we have.
>
>>  But I needed a
>> solution to this much quicker than that. I am not really expecting
>> Yocto to fix a libtool problem. I only wished to flag for the problem
>> and provide the patch if more people stumble into the same issue. And
>> sure, I can try to post this patch in a proper way. I will probably
>> mess it up, but there is a first time for everything ;)
>
> Indeed, the first time you do this its quite daunting but equally, we'll
> do our best to help you through it and its not actually so bad. I'm
> suggesting you do go through the process since if you then later have
> other changes, you'll be more likely to submit them too and I would
> encourage people to do that.
>
>>  Is there some
>> document that describes the exact procedure for sending a patch for
>> review in Yocto?
>
> http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#how-to-submit-a-change
>
> Don't worry about maintainers and so on for this one, just send it to
> the OE-Core list.
>
>>  I guess you also wish to have some ticket id or
>> something to connect it to?
>
> Its not essential in a case like this where the issue is now well
> understood.
>
>> As it stands right now we have a .bbappend to workaround this so there
>> is really no panic.
>
> If its going to be in the release which I'd like it to be, I could do
> with it sooner than later though. If you don't have the time, fair
> enough but it does seem like a good fix.
>

Ok, I will see what I can do. I guess ch3.9+ch3.9.2 is what I need to
walk through.

> Cheers,
>
> Richard
>
>
>