[OE-core] [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 at linux.intel.com> wrote:
>> On 02/25/2013 03:40 AM, Marko Lindqvist wrote:
>>>
>>> On 20 February 2013 16:32, Marko Lindqvist <cazfi74 at gmail.com> wrote:
>>>>
>>>> On 19 February 2013 19:12, Saul Wold <sgw at 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
>
>