| Message ID | cover.1361091390.git.cazfi74@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 02/17/2013 01:00 AM, Marko Lindqvist wrote: > A couple of automake-1.13 related fixes and updates to newer upstream > versions. Notably curl now has its official automake-1.13 support, so > we get rid of our own hack. > > The following changes since commit 97aa5ac2df7593e343d82f5e64a422bb951eacf9: > > dropbear: use pidfile for daemon start/stop/restart (2013-02-15 12:58:44 +0000) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib cazfi/misc > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/misc > > Marko Lindqvist (5): > webkit-gtk: replace obsolete automake macros with working ones > gtk-sato-engine: update to git repository head > oprofileui-server: replace obsolete automake macros with working ones > libffi: update to upstream version 3.0.12 Not sure what's going on but I saw a batch of failures with glib-2.0, take a look at the autobuilder failure: http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio or http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio Not sure why, but glib-2.0 is not finding the libffi library, but it seems to exist in the sysroot. Thanks Sau! > curl: update to upstream version 7.29.0 > > .../libffi/0001-libffi-update-for-3.0.11.patch | 171 -- > .../libffi/aarch64-adding-build-support.patch | 63 - > .../libffi/libffi/add-aarch64-support.patch | 2672 -------------------- > .../libffi/{libffi_3.0.11.bb => libffi_3.0.12.bb} | 9 +- > .../obsolete_automake_macros.patch | 20 + > .../oprofile/oprofileui-server_git.bb | 6 +- > .../gtk-engines/gtk-sato-engine_git.bb | 4 +- > .../obsolete_automake_macros.patch | 14 + > meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb | 3 +- > .../dont_override_ac_config_macro_dir.patch | 30 - > .../curl-7.28.1/obsolete_automake_macros.patch | 14 - > meta/recipes-support/curl/curl/pkgconfig_fix.patch | 25 +- > .../curl/{curl_7.28.1.bb => curl_7.29.0.bb} | 8 +- > 13 files changed, 59 insertions(+), 2980 deletions(-) > delete mode 100644 meta/recipes-gnome/libffi/libffi/0001-libffi-update-for-3.0.11.patch > delete mode 100644 meta/recipes-gnome/libffi/libffi/aarch64-adding-build-support.patch > delete mode 100644 meta/recipes-gnome/libffi/libffi/add-aarch64-support.patch > rename meta/recipes-gnome/libffi/{libffi_3.0.11.bb => libffi_3.0.12.bb} (76%) > create mode 100644 meta/recipes-kernel/oprofile/oprofileui-server/obsolete_automake_macros.patch > create mode 100644 meta/recipes-sato/webkit/webkit-gtk-1.8.3/obsolete_automake_macros.patch > delete mode 100644 meta/recipes-support/curl/curl-7.28.1/dont_override_ac_config_macro_dir.patch > delete mode 100644 meta/recipes-support/curl/curl-7.28.1/obsolete_automake_macros.patch > rename meta/recipes-support/curl/{curl_7.28.1.bb => curl_7.29.0.bb} (88%) >
On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote: > On 02/17/2013 01:00 AM, Marko Lindqvist wrote: >> libffi: update to upstream version 3.0.12 > > Not sure what's going on but I saw a batch of failures with glib-2.0, take a > look at the autobuilder failure: > > http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio > > or > > http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio > > Not sure why, but glib-2.0 is not finding the libffi library, but it seems > to exist in the sysroot. I should be able to take a brief look next weekend, but tonight and tomorrow I'm busy with other things. - ML
On 20 February 2013 16:32, Marko Lindqvist <cazfi74@gmail.com> wrote: > On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote: >> On 02/17/2013 01:00 AM, Marko Lindqvist wrote: >>> libffi: update to upstream version 3.0.12 >> >> Not sure what's going on but I saw a batch of failures with glib-2.0, take a >> look at the autobuilder failure: >> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio >> >> or >> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio >> >> Not sure why, but glib-2.0 is not finding the libffi library, but it seems >> to exist in the sysroot. > > I should be able to take a brief look next weekend, but tonight and > tomorrow I'm busy with other things. I've found no way to reproduce this on my own computer no matter how I've tried to invalidate parts of the cache etc. but I wonder if it could be that for some reason libffi didn't exist in sysroot already at the time it was needed, only later when you checked for it. I see no problem with glib-2.0-native dependencies, though. Note that in the log there's: NOTE: Running noexec task 5283 of 7886 (ID: 3244, virtual:native:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/meta/recipes-gnome/libffi/libffi_3.0.12.bb, do_build) AFTER glib2.0-native build has failed. One thing that may play a role here is that libffi does not depend on anything, not even libffi-native. Libffi seems to be built already before libffi-native. - ML
On 02/25/2013 03:40 AM, Marko Lindqvist wrote: > On 20 February 2013 16:32, Marko Lindqvist <cazfi74@gmail.com> wrote: >> On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote: >>> On 02/17/2013 01:00 AM, Marko Lindqvist wrote: >>>> libffi: update to upstream version 3.0.12 >>> >>> Not sure what's going on but I saw a batch of failures with glib-2.0, take a >>> look at the autobuilder failure: >>> >>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio >>> >>> or >>> >>> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio >>> >>> Not sure why, but glib-2.0 is not finding the libffi library, but it seems >>> to exist in the sysroot. >> >> I should be able to take a brief look next weekend, but tonight and >> tomorrow I'm busy with other things. > > I've found no way to reproduce this on my own computer no matter how > I've tried to invalidate parts of the cache etc. but I wonder if it > could be that for some reason libffi didn't exist in sysroot already > at the time it was needed, only later when you checked for it. I see > no problem with glib-2.0-native dependencies, though. > I found a way to reproduce it and fix it, I believe! Just curious, what's your build host arch? and what does gcc -print-multi-os-directory return on your host? It returns lib64 on my host and it causes the libs to be installed in the <WORKDIR>/image/usr/lib64 dir and not get picked up by the populate_sysroot() code. I commented out some code in configure.ac and that seems to have solved the problem, but I am not sure if we need to start adding lib64 to populate_sysroot or tweaking configure code! Sau! > Note that in the log there's: > NOTE: Running noexec task 5283 of 7886 (ID: 3244, > virtual:native:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/meta/recipes-gnome/libffi/libffi_3.0.12.bb, > do_build) > AFTER glib2.0-native build has failed. > > One thing that may play a role here is that libffi does not depend on > anything, not even libffi-native. Libffi seems to be built already > before libffi-native. > > > - ML >
On 26 February 2013 00:34, Saul Wold <sgw@linux.intel.com> wrote: > On 02/25/2013 03:40 AM, Marko Lindqvist wrote: >> >> On 20 February 2013 16:32, Marko Lindqvist <cazfi74@gmail.com> wrote: >>> >>> On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote: >>>> >>>> On 02/17/2013 01:00 AM, Marko Lindqvist wrote: >>>>> >>>>> libffi: update to upstream version 3.0.12 >>>> >>>> >>>> Not sure what's going on but I saw a batch of failures with glib-2.0, >>>> take a >>>> look at the autobuilder failure: >>>> >>>> >>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio >>>> >>>> or >>>> >>>> >>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio >>>> >>>> Not sure why, but glib-2.0 is not finding the libffi library, but it >>>> seems >>>> to exist in the sysroot. >>> >>> >>> I should be able to take a brief look next weekend, but tonight and >>> tomorrow I'm busy with other things. >> >> >> I've found no way to reproduce this on my own computer no matter how >> I've tried to invalidate parts of the cache etc. but I wonder if it >> could be that for some reason libffi didn't exist in sysroot already >> at the time it was needed, only later when you checked for it. I see >> no problem with glib-2.0-native dependencies, though. >> > I found a way to reproduce it and fix it, I believe! > > Just curious, what's your build host arch? and what does gcc > -print-multi-os-directory return on your host? x86_64-linux > gcc -print-multi-os-directory ../lib > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) > It returns lib64 on my host and it causes the libs to be installed in the > <WORKDIR>/image/usr/lib64 dir and not get picked up by the > populate_sysroot() code. > > I commented out some code in configure.ac and that seems to have solved the > problem, but I am not sure if we need to start adding lib64 to > populate_sysroot or tweaking configure code! > > Sau! - ML
On 02/25/2013 11:42 PM, Marko Lindqvist wrote: > On 26 February 2013 00:34, Saul Wold <sgw@linux.intel.com> wrote: >> On 02/25/2013 03:40 AM, Marko Lindqvist wrote: >>> >>> On 20 February 2013 16:32, Marko Lindqvist <cazfi74@gmail.com> wrote: >>>> >>>> On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote: >>>>> >>>>> On 02/17/2013 01:00 AM, Marko Lindqvist wrote: >>>>>> >>>>>> libffi: update to upstream version 3.0.12 >>>>> >>>>> >>>>> Not sure what's going on but I saw a batch of failures with glib-2.0, >>>>> take a >>>>> look at the autobuilder failure: >>>>> >>>>> >>>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio >>>>> >>>>> or >>>>> >>>>> >>>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio >>>>> >>>>> Not sure why, but glib-2.0 is not finding the libffi library, but it >>>>> seems >>>>> to exist in the sysroot. >>>> >>>> >>>> I should be able to take a brief look next weekend, but tonight and >>>> tomorrow I'm busy with other things. >>> >>> >>> I've found no way to reproduce this on my own computer no matter how >>> I've tried to invalidate parts of the cache etc. but I wonder if it >>> could be that for some reason libffi didn't exist in sysroot already >>> at the time it was needed, only later when you checked for it. I see >>> no problem with glib-2.0-native dependencies, though. >>> >> I found a way to reproduce it and fix it, I believe! >> >> Just curious, what's your build host arch? and what does gcc >> -print-multi-os-directory return on your host? > > x86_64-linux > > > gcc -print-multi-os-directory > ../lib > Interesting, I get ../lib64 from that on a Fedora 18 machines my gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Even after I commented out this code in configure.ac, I was then getting gconf (a dependee of libffi) complaining about a redunant RPATH which also traced down to the newer version of libffi! There seems to be some issue lurking here with configure and libtool. Sau! > > gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian > 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs > --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-4.7 --enable-shared --enable-linker-build-id > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --enable-gnu-unique-object --enable-plugin --enable-objc-gc > --with-arch-32=i586 --with-tune=generic --enable-checking=release > --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.7.2 (Debian 4.7.2-5) > > >> It returns lib64 on my host and it causes the libs to be installed in the >> <WORKDIR>/image/usr/lib64 dir and not get picked up by the >> populate_sysroot() code. >> >> I commented out some code in configure.ac and that seems to have solved the >> problem, but I am not sure if we need to start adding lib64 to >> populate_sysroot or tweaking configure code! >> >> Sau! > > > - ML > >
On 26 February 2013 09:52, Saul Wold <sgw@linux.intel.com> wrote: > > There seems to be some issue lurking here with configure and libtool. > > Sau! libffi seems to include all the libtool m4-files, updated between libffi-3.0.11 and libffi-3.0.12. These might be incompatible with libtool files in your system, or does the build force them to be replaced (libtoolize -f)? I've got around a bit similar problems (not in OE, but building in general) by simply deleting m4/libtool.m4 m4/lt*.m4 from the project, and letting libtoolize/autoreconf to place correct versions there instead. Could you test that? - ML
FYI On Tue, Feb 26, 2013 at 2:52 AM, Saul Wold <sgw@linux.intel.com> wrote: >>> Just curious, what's your build host arch? and what does gcc >>> -print-multi-os-directory return on your host? on openSUSE 12.2 $ uname -a Linux codei7 3.4.28-2.20-desktop #1 SMP PREEMPT Tue Jan 29 16:51:37 UTC 2013 (143156b) x86_64 x86_64 x86_64 GNU/Linux $ gcc -print-multi-os-directory ../lib64 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
A couple of automake-1.13 related fixes and updates to newer upstream versions. Notably curl now has its official automake-1.13 support, so we get rid of our own hack. The following changes since commit 97aa5ac2df7593e343d82f5e64a422bb951eacf9: dropbear: use pidfile for daemon start/stop/restart (2013-02-15 12:58:44 +0000) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib cazfi/misc http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/misc Marko Lindqvist (5): webkit-gtk: replace obsolete automake macros with working ones gtk-sato-engine: update to git repository head oprofileui-server: replace obsolete automake macros with working ones libffi: update to upstream version 3.0.12 curl: update to upstream version 7.29.0 .../libffi/0001-libffi-update-for-3.0.11.patch | 171 -- .../libffi/aarch64-adding-build-support.patch | 63 - .../libffi/libffi/add-aarch64-support.patch | 2672 -------------------- .../libffi/{libffi_3.0.11.bb => libffi_3.0.12.bb} | 9 +- .../obsolete_automake_macros.patch | 20 + .../oprofile/oprofileui-server_git.bb | 6 +- .../gtk-engines/gtk-sato-engine_git.bb | 4 +- .../obsolete_automake_macros.patch | 14 + meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb | 3 +- .../dont_override_ac_config_macro_dir.patch | 30 - .../curl-7.28.1/obsolete_automake_macros.patch | 14 - meta/recipes-support/curl/curl/pkgconfig_fix.patch | 25 +- .../curl/{curl_7.28.1.bb => curl_7.29.0.bb} | 8 +- 13 files changed, 59 insertions(+), 2980 deletions(-) delete mode 100644 meta/recipes-gnome/libffi/libffi/0001-libffi-update-for-3.0.11.patch delete mode 100644 meta/recipes-gnome/libffi/libffi/aarch64-adding-build-support.patch delete mode 100644 meta/recipes-gnome/libffi/libffi/add-aarch64-support.patch rename meta/recipes-gnome/libffi/{libffi_3.0.11.bb => libffi_3.0.12.bb} (76%) create mode 100644 meta/recipes-kernel/oprofile/oprofileui-server/obsolete_automake_macros.patch create mode 100644 meta/recipes-sato/webkit/webkit-gtk-1.8.3/obsolete_automake_macros.patch delete mode 100644 meta/recipes-support/curl/curl-7.28.1/dont_override_ac_config_macro_dir.patch delete mode 100644 meta/recipes-support/curl/curl-7.28.1/obsolete_automake_macros.patch rename meta/recipes-support/curl/{curl_7.28.1.bb => curl_7.29.0.bb} (88%)