[OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

[Hans Beckérus]

On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold <sgw at linux.intel.com> wrote:
> On 09/11/2013 09:05 AM, Hans Beckérus wrote:
>>
>> On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus <hans.beckerus at gmail.com>
>> wrote:
>>>
>>> On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold <sgw at linux.intel.com> wrote:
>>>>
>>>> On 09/10/2013 07:56 AM, hans.beckerus at gmail.com wrote:
>>>>>
>>>>>
>>>>> From: Hans Beckerus <hans.beckerus at gmail.com>
>>>>>
>>>>> This patch updates libtool.m4 (and its output) to resolve a problem
>>>>> with variable 'lt_sysroot' not being properly updated if the option
>>>>> '--with[-libtool]-sysroot' is not provided when running the 'configure'
>>>>> script for a package.
>>>>>
>>>>> According to the help text ouput from 'configure':
>>>>> --with-libtool-sysroot=DIR Search for dependent libraries within DIR
>>>>>                          (or the compiler's sysrooot if not specified).
>>>>>
>>>>> Due to swapped cases in a switch statement, when checking if the option
>>>>> was specified or not, wrong actions were taken resulting in an
>>>>> incorrect sysroot and failures to properly locate e.g. .la files.
>>>>>
>>>> What kind of testing have you done with this?  Have you tried a full
>>>> world
>>>> build?  This kind of change scares me a little as what issues we might
>>>> have
>>>> patched around or behavior built into software.
>>>>
>>> In the area of testing, it has been verified in my local environment,
>>> which covers a few different ARM based images and SDK installs. I have
>>> not done a build of all possible packages in my Yocto branch.
>>>
>>>> I just completed a world build locally and have failures in file-native
>>>> guile-native, and gtk+3, not sure if we need to invalidate sstate, I am
>>>> starting a clean build.
>>>>
>>> I have no issues with neither of those packages, at least not in
>>> stand-alone builds.
>>> Can you specify a little more exactly what goes wrong during the build
>>> stage?
>>>
>> Actually, someone else here hit a couple of packages that had  SDK
>> build failures after applying the patch.
>> In this case it was gettext-native and gnutls-native. After doing a
>> 'cleanall' of those packages rebuild went fine.
>> So, yes, sstate should probably be invalidated after a change like
>> this since some packages does not seem to be rebuilt properly
>> otherwise. Are they missing a DEPEND to libtool maybe?
>>
> No, these are from a clean build space with no sstate either, I wanted to
> verify that.
>
> Also, anything that inherits autotools automagically gets a libtool
> dependency added, so we should not be adding that kind of dependency in
> recipes.
>
> I have attached the 3 failures I saw for a completely clean build, note
> these are native tools: file-native, guile-native and apr-util-native.
>
Again, I have no issues what so ever to build these packages one by
one after a clean sstate.
On the other hand, I am on a poky 1.4 baseline. I need to bring in the
latest oe-core and build world from there.

Hans

>
> Sau!
>
>
>>> Thanks,
>>> Hans
>>>
>>>> I have not dug too deeply into this yet.
>>>>
>>>> Sau!
>>>>
>>>>
>>>>
>>>>
>>>>> For current upstream status see:
>>>>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg00005.html
>>>>>
>>>>> Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>
>>>>> ---
>>>>>    meta/recipes-devtools/libtool/libtool-2.4.2.inc    |  1 +
>>>>>    .../libtool/libtool/fix-resolve-lt-sysroot.patch   | 35
>>>>> ++++++++++++++++++++++
>>>>>    2 files changed, 36 insertions(+)
>>>>>    create mode 100644
>>>>> meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
>>>>>
>>>>> diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>>> b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>>> index bb4ddf0..92e4949 100644
>>>>> --- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
>>>>> @@ -20,6 +20,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz
>>>>> \
>>>>>             file://respect-fstack-protector.patch \
>>>>>               file://norm-rpath.patch \
>>>>>               file://dont-depend-on-help2man.patch \
>>>>> +           file://fix-resolve-lt-sysroot.patch \
>>>>>              "
>>>>>
>>>>>    SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
>>>>> diff --git
>>>>> a/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
>>>>> b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
>>>>> new file mode 100644
>>>>> index 0000000..5a6335b
>>>>> --- /dev/null
>>>>> +++
>>>>> b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
>>>>> @@ -0,0 +1,35 @@
>>>>> +
>>>>> +Upstream-Status: Pending
>>>>> +
>>>>> +This patch updates libtool.m4 (and its output) to resolve a problem
>>>>> +with variable 'lt_sysroot' not being properly updated if the option
>>>>> +'--with[-libtool]-sysroot' is not provided when running the
>>>>> 'configure'
>>>>> +script for a package.
>>>>> +
>>>>> +I have also reported the problem to libtool here
>>>>> +
>>>>> +http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg00005.html
>>>>> +
>>>>> +Signed-off-by: Hans Beckerus <hans.beckerus at gmail.com>
>>>>> +---
>>>>> +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}])
>>>>>
>>>>
>>
>>
>