On 09/11/2013 09:05 AM, Hans Beckérus wrote: > On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus wrote: >> On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold wrote: >>> On 09/10/2013 07:56 AM, hans.beckerus@gmail.com wrote: >>>> >>>> From: Hans Beckerus >>>> >>>> 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. 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 >>>> --- >>>> 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 >>>> +--- >>>> +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}]) >>>> >>> > >