[PATCH 0/5] automake-1.13 and upstream version updates

[PATCH 0/5] automake-1.13 and upstream version updates

[Marko Lindqvist]

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%)

-- 
1.7.10.4

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Saul Wold]

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%)
>

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Marko Lindqvist]

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

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Marko Lindqvist]

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

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Saul Wold]

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
>

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Marko Lindqvist]

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

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Saul Wold]

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
>
>

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Marko Lindqvist]

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

Re: [PATCH 0/5] automake-1.13 and upstream version updates

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

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)

[-- Attachment #2: Type: text/html, Size: 2079 bytes --]