[OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
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
+)
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%)
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
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
+)
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%)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 19 February 2013 19:12, Saul Wold 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 20 February 2013 16:32, Marko Lindqvist wrote: > On 19 February 2013 19:12, Saul Wold 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 02/25/2013 03:40 AM, Marko Lindqvist wrote: On 20 February 2013 16:32, Marko Lindqvist wrote: On 19 February 2013 19:12, Saul Wold 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 /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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 26 February 2013 00:34, Saul Wold wrote: > On 02/25/2013 03:40 AM, Marko Lindqvist wrote: >> >> On 20 February 2013 16:32, Marko Lindqvist wrote: >>> >>> On 19 February 2013 19:12, Saul Wold 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 > /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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 02/25/2013 11:42 PM, Marko Lindqvist wrote: On 26 February 2013 00:34, Saul Wold wrote: On 02/25/2013 03:40 AM, Marko Lindqvist wrote: On 20 February 2013 16:32, Marko Lindqvist wrote: On 19 February 2013 19:12, Saul Wold 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 /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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
On 26 February 2013 09:52, Saul Wold 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/5] automake-1.13 and upstream version updates
FYI On Tue, Feb 26, 2013 at 2:52 AM, Saul Wold 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) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
