From: Hans Beckerus <hans.beckerus@gmail.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v4] libtool: fix resolve of lt_sysroot
Date: Thu, 12 Sep 2013 23:09:31 +0200 [thread overview]
Message-ID: <52322D8B.7080406@gmail.com> (raw)
In-Reply-To: <CAFyqS9r3WOEjfrPe5s=n1H9SzFsnJ4FAdo=AGprWUkufUe6QRQ@mail.gmail.com>
On 2013-09-12 8:02, Hans Beckérus wrote:
> On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold <sgw@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@gmail.com>
>>> wrote:
>>>> On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>> On 09/10/2013 07:56 AM, hans.beckerus@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.
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
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.
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}])
>>>>>>
>>>
next prev parent reply other threads:[~2013-09-12 21:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 14:56 [PATCH v4] libtool: fix resolve of lt_sysroot hans.beckerus
2013-09-10 21:33 ` Saul Wold
2013-09-11 8:15 ` Hans Beckérus
2013-09-11 16:05 ` Hans Beckérus
2013-09-12 17:09 ` Saul Wold
2013-09-12 18:02 ` Hans Beckérus
2013-09-12 21:09 ` Hans Beckerus [this message]
2013-09-12 21:50 ` Saul Wold
2013-09-12 23:07 ` Hans Beckerus
2013-09-13 8:06 ` Hans Beckérus
2013-09-13 8:52 ` Richard Purdie
2013-09-13 9:01 ` Hans Beckérus
2013-09-13 9:08 ` Hans Beckérus
2013-09-13 9:53 ` Hans Beckérus
2013-09-13 12:14 ` Hans Beckérus
2013-09-13 12:21 ` Richard Purdie
2013-09-13 13:08 ` Hans Beckérus
2013-09-13 13:29 ` Hans Beckérus
2013-09-13 17:49 ` Saul Wold
2013-09-13 18:03 ` Hans Beckerus
2013-09-13 19:30 ` Hans Beckerus
2013-09-13 20:36 ` Saul Wold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52322D8B.7080406@gmail.com \
--to=hans.beckerus@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=sgw@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox