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

Saul Wold sgw at linux.intel.com
Thu Sep 12 21:50:15 UTC 2013 

On 09/12/2013 02:09 PM, Hans Beckerus wrote:
> On 2013-09-12 8:02, Hans Beckérus wrote:
>> 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.
> I have now tried a world build on oe-core master/latest and I can
> confirm that also I get build errors on a clean build root.
> I only went as far as stopping at file-native. I think I need to debug
> this problem package by package. Something is definitely spooky here.

Spooky is the right word for it, I was not sure what was going on and do 
not have the time to spend on it right now, that's why I kicked it back 
your way.

> On poky 1.4 it works like a charm, on current oe-core it does not. Also,
> doing a clean sstate or building "file-native" separately
> makes no difference.  What I discovered is that the sysroot is
> completely wrong. It has been resolved to "/" which means the wrong
> set of libraries are picked up. If I patched the generated
> x86_64-linux-libtool and replaced lt_sysroot with the actual sysroot in use
> compilation went fine! The libtool patch *is* good. No question about
Right, I understand that, it's just the behavior has now changed and 
other things may have relied on the broken behavior.

> that. It is an obvious bug that has been corrected. To me this looks like
> some kind of  a double-fault! I need to dig deeper.
>
I was kind of wondering if somehow some of those upstreams worked around 
the problem in libtool and now that you fixed it, there is strange breakage.

Thanks for confirming the issue and digging into it, these fixes might 
have to go upstream also.

Sau!


> Thanks.
> Hans
>
>> 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}])
>>>>>>>
>>>>
>
>
>

More information about the Openembedded-core mailing list