On 02/25/2013 11:42 PM, Marko Lindqvist wrote:
On 26 February 2013 00:34, Saul Wold <[email protected]> wrote:
On 02/25/2013 03:40 AM, Marko Lindqvist wrote:
On 20 February 2013 16:32, Marko Lindqvist <[email protected]> wrote:
On 19 February 2013 19:12, Saul Wold <[email protected]> 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
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
