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

Hans Beckérus hans.beckerus at gmail.com
Wed Sep 11 16:05:18 UTC 2013


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?

> 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}])
>>>
>>



More information about the Openembedded-core mailing list