Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

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

Downloaded the latest, and tried building console-image for qemuarm.
Host = Ubuntu 11.04 i686.

Looked through the build log, and thought I'd share it with the list.


A number of warnings (see below)

Seen a couple of errors as well.

1.    ERROR: Function 'useradd_sysroot' failed
         Tried to access "/etc/group" but this was locked.
         Problem disappeared the next time I rebuilt.

2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer 
available.
         tzdata , same problem.
         The recipe is located in two places.
         meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the 
problem
         This is what the build uses.

3.    When I ran into this problem, I exited with ctrl-C.
         This left some recipes in the middle of a fetch ,and the build 
could not continue.
         I had to "bitbake -c clean <package>" on all problematic 
packages to recover.
         Seems a little bit fragile to me.

4.     linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
         Fails in the fetch stage.
         I removed the layer, since it was not needed for qemuarm.

5.    When compiling on a Ubuntu 11.10 x64 host  (linux 3.x host)
         tiff won't build.
         Did:
             bitbake console-image"
             bitbake -c clean tiff
             bitbake  tiff
         - No luck
         Reading through the mailing list, I found someone which deleted
         $TMPDIR and then
             bitbake tiff
             bitbake console-image
         That worked for me as well once, second time, same problem.
         Problem is that #include <iostream> fails.

         I noted that "iostream" is built and available in 
<sysroot>/usr/include/c++
         On the host, it is located in /usr/incolude/c++/<version>
         "tiff" build seems to be OK with Ubuntu 11.04 i686.

BR
Ulf Samuelsson


------------------------------------------------------------------------------------------
The following packages could not be downloaded.

http://kernel.org/pub/linux/utils/util-linux-ng/v2.19/util-linux-2.19.1.tar.bz2
http://kernel.org/pub/linux/libs/pam/library/Linux-PAM-1.1.4.tar.bz2
http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz
http://kernel.org/pub/linux/utils/kernel/module-init-tools/module-init-tools-3.16.tar.bz2
http://kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.22.tar.bz2
http://kernel.org/pub/linux/utils/usb/usbutils/usbutils-0.91.tar.gz
http://kernel.org/pub/linux/bluetooth/bluez-4.96.tar.gz
http://www.kernel.org/pub/linux/bluetooth/bluez-hcidump-2.1.tar.gz
http://kernel.org/pub/linux/utils/kbd/kbd-1.15.2.tar.bz2
http://kernel.org/pub/linux/utils/kernel/pcmcia/pcmciautils-018.tar.bz2
http://www.kernel.org/pub/linux/network/connman/connman-0.77.tar.gz
ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz


WARNING: zip: No generic license file exists for: Info-ZIP at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: zip: There is also no SPDXLICENSEMAP for this license type: 
Info-ZIP at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: tcp-wrappers: No generic license file exists for: tcp-wrappers 
at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: tcp-wrappers: There is also no SPDXLICENSEMAP for this license 
type: tcp-wrappers at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: Missing md5 SRC_URI checksum for 
/home/downloads/downloads/hicolor-icon-theme-0.12.tar.gz, consider 
adding to the recipe:
SRC_URI[md5sum] = "55cafbcef8bcf7107f6d502149eb4d87"
WARNING: Missing sha256 SRC_URI checksum for 
/home/downloads/downloads/hicolor-icon-theme-0.12.tar.gz, consider 
adding to the recipe:
SRC_URI[sha256sum] = 
"9edca690617eaa19054951ca53501c802180262be8880ed84754ac46c93bec73"

WARNING: perl: No generic license file exists for: Artistic|GPL at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: perl: There is also no SPDXLICENSEMAP for this license type: 
Artistic|GPL at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: gmp: No generic license file exists for: LGPLv3&GPLv3 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: gmp: There is also no SPDXLICENSEMAP for this license type: 
LGPLv3&GPLv3 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: bzip2: No generic license file exists for: bzip2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: bzip2: There is also no SPDXLICENSEMAP for this license type: 
bzip2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: busybox: No generic license file exists for: bzip2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: busybox: There is also no SPDXLICENSEMAP for this license type: 
bzip2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: ntp: No generic license file exists for: ntp at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: ntp: There is also no SPDXLICENSEMAP for this license type: ntp 
at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: For recipe resolvconf, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/sbin

WARNING: 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/qemuarm-angstrom-linux-gnueabi/sysvinit-inittab-2.88dsf-r6/sysvinit-2.88dsf/COPYING 
could not be copied for some reason. It may not exist. WARN for now.

WARNING: python: No generic license file exists for: PSFv2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: python: There is also no SPDXLICENSEMAP for this license type: 
PSFv2 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: dnsmasq-dbus: No generic license file exists for: GPLv2GPLv3 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: dnsmasq-dbus: There is also no SPDXLICENSEMAP for this license 
type: GPLv2GPLv3 at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: elfutils: No generic license file exists for: Exception at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: elfutils: There is also no SPDXLICENSEMAP for this license 
type: Exception at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: libgcc: No generic license file exists for: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: libgcc: There is also no SPDXLICENSEMAP for this license type: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: gcc-cross: No generic license file exists for: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: gcc-cross: There is also no SPDXLICENSEMAP for this license 
type: GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: gcc-cross-initial: No generic license file exists for: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: gcc-cross-initial: There is also no SPDXLICENSEMAP for this 
license type: GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: gcc-cross-intermediate: No generic license file exists for: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: gcc-cross-intermediate: There is also no SPDXLICENSEMAP for 
this license type: GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: gcc-runtime: No generic license file exists for: 
GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses
WARNING: gcc-runtime: There is also no SPDXLICENSEMAP for this license 
type: GCCRUNTIMELIBRARYEXCEPTION at 
/home/ulf/projects/OE_core/setup-scripts/sources/openembedded-core/meta/files/common-licenses

WARNING: For recipe eglibc, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/locale

WARNING: For recipe libgcc, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/src
WARNING:   /usr/src/debug

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/libgcc-4.5-r43+svnr178923/packages-split/libgcc/lib/libgcc_s.so.1'

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipsplit'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zip'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipnote'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/zip-3.0-r0/packages-split/zip/usr/bin/zipcloak'

WARNING: For recipe ncurses, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/terminfo

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/gdbm-1.8.3-r4/packages-split/gdbm/usr/lib/libgdbm.so.3.0.0'

WARNING: For recipe openssl, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/engines
WARNING:   /usr/lib/ssl/private
WARNING:   /usr/lib/ssl/certs

WARNING: For recipe readline, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/bin
WARNING: QA Issue: readline: 
/work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libhistory.so.6 
contains probably-redundant RPATH /usr/lib
WARNING: QA Issue: readline: 
/work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libhistory.so.6.2 
contains probably-redundant RPATH /usr/lib
WARNING: QA Issue: readline: 
/work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libreadline.so.6.2 
contains probably-redundant RPATH /usr/lib
WARNING: QA Issue: readline: 
/work/armv5te-angstrom-linux-gnueabi/readline-6.2-r0/packages-split/readline/usr/lib/libreadline.so.6 
contains probably-redundant RPATH /usr/lib

WARNING: For recipe cracklib, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/python2.7
WARNING:   /usr/lib/python2.7/site-packages

WARNING: For recipe libcgroup, the following files/directories were 
installed but not shipped in any package:
WARNING:   /lib/security/pam_cgroup.la
WARNING:   /lib/security/.debug
WARNING:   /lib/security/.debug/pam_cgroup.so
WARNING:   /lib/security/.debug/pam_cgroup.so.0.0.0
WARNING:   /lib/security/.debug/pam_cgroup.so.0
WARNING: For recipe libgcrypt, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/sbin

WARNING: For recipe dbus, the following files/directories were installed 
but not shipped in any package:
WARNING:   /usr/lib/dbus-1.0/test

WARNING: For recipe glib-2.0, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/gio
WARNING:   /usr/lib/gio/modules

WARNING: For recipe perl, the following files/directories were installed 
but not shipped in any package:
WARNING:   /usr/lib/perl/site_perl
WARNING:   /usr/lib/perl/site_perl/5.14.2

WARNING: For recipe angstrom-version, the following files/directories 
were installed but not shipped in any package:
WARNING:   /usr/src
WARNING:   /usr/src/debug

WARNING: For recipe dbus-glib, the following files/directories were 
installed but not shipped in any package:
WARNING:   /etc
WARNING:   /etc/bash_completion.d
WARNING:   /etc/bash_completion.d/dbus-bash-completion.sh
WARNING:   /usr/libexec/dbus-bash-completion-helper

WARNING: For recipe alsa-utilsWARNING, the following files/directories 
were installed but not shipped in any package:
WARNING:   /var
WARNING:   /var/lib
WARNING:   /var/lib/alsa
WARNING: For recipe udev, the following files/directories were installed 
but not shipped in any package:
WARNING:   /usr/sbin

WARNING: For recipe avahi, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/avahi

WARNING: For recipe bluez4, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/bluetooth
WARNING:   /usr/lib/bluetooth/plugins

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-lib/usr/lib/libperl.so.5.14.2'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-symbol/usr/lib/perl/5.14.2/auto/Encode/Symbol/Symbol.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-unicode/usr/lib/perl/5.14.2/auto/Encode/Unicode/Unicode.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-jp/usr/lib/perl/5.14.2/auto/Encode/JP/JP.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-cn/usr/lib/perl/5.14.2/auto/Encode/CN/CN.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-tw/usr/lib/perl/5.14.2/auto/Encode/TW/TW.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-kr/usr/lib/perl/5.14.2/auto/Encode/KR/KR.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-byte/usr/lib/perl/5.14.2/auto/Encode/Byte/Byte.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode-ebcdic/usr/lib/perl/5.14.2/auto/Encode/EBCDIC/EBCDIC.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-b/usr/lib/perl/5.14.2/auto/B/B.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-unicode/usr/lib/perl/5.14.2/auto/Unicode/Normalize/Normalize.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-unicode/usr/lib/perl/5.14.2/auto/Unicode/Collate/Collate.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-mro/usr/lib/perl/5.14.2/auto/mro/mro.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-posix/usr/lib/perl/5.14.2/auto/POSIX/POSIX.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-fcntl/usr/lib/perl/5.14.2/auto/Fcntl/Fcntl.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/PPPort/PPPort.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/Peek/Peek.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-devel/usr/lib/perl/5.14.2/auto/Devel/DProf/DProf.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-io/usr/lib/perl/5.14.2/auto/IO/IO.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-list/usr/lib/perl/5.14.2/auto/List/Util/Util.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-opcode/usr/lib/perl/5.14.2/auto/Opcode/Opcode.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-cwd/usr/lib/perl/5.14.2/auto/Cwd/Cwd.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-file/usr/lib/perl/5.14.2/auto/File/Glob/Glob.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-compress/usr/lib/perl/5.14.2/auto/Compress/Raw/Bzip2/Bzip2.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-compress/usr/lib/perl/5.14.2/auto/Compress/Raw/Zlib/Zlib.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sdbm-file/usr/lib/perl/5.14.2/auto/SDBM_File/SDBM_File.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-attributes/usr/lib/perl/5.14.2/auto/attributes/attributes.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-math/usr/lib/perl/5.14.2/auto/Math/BigInt/FastCalc/FastCalc.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-text/usr/lib/perl/5.14.2/auto/Text/Soundex/Soundex.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-re/usr/lib/perl/5.14.2/auto/re/re.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sys/usr/lib/perl/5.14.2/auto/Sys/Syslog/Syslog.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-sys/usr/lib/perl/5.14.2/auto/Sys/Hostname/Hostname.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-threads/usr/lib/perl/5.14.2/auto/threads/threads.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-threads/usr/lib/perl/5.14.2/auto/threads/shared/shared.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-storable/usr/lib/perl/5.14.2/auto/Storable/Storable.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-hash/usr/lib/perl/5.14.2/auto/Hash/Util/Util.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-hash/usr/lib/perl/5.14.2/auto/Hash/Util/FieldHash/FieldHash.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-ipc/usr/lib/perl/5.14.2/auto/IPC/SysV/SysV.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-digest/usr/lib/perl/5.14.2/auto/Digest/MD5/MD5.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-digest/usr/lib/perl/5.14.2/auto/Digest/SHA/SHA.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-gdbm-file/usr/lib/perl/5.14.2/auto/GDBM_File/GDBM_File.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-i18n/usr/lib/perl/5.14.2/auto/I18N/Langinfo/Langinfo.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-data/usr/lib/perl/5.14.2/auto/Data/Dumper/Dumper.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-filter/usr/lib/perl/5.14.2/auto/Filter/Util/Call/Call.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-socket/usr/lib/perl/5.14.2/auto/Socket/Socket.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-time/usr/lib/perl/5.14.2/auto/Time/HiRes/HiRes.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-time/usr/lib/perl/5.14.2/auto/Time/Piece/Piece.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/encoding/encoding.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/scalar/scalar.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-perlio/usr/lib/perl/5.14.2/auto/PerlIO/via/via.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-mime/usr/lib/perl/5.14.2/auto/MIME/Base64/Base64.so'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/perl-5.14.2-r0/packages-split/perl-module-encode/usr/lib/perl/5.14.2/auto/Encode/Encode.so'

WARNING: For recipe ntp, the following files/directories were installed 
but not shipped in any package:
WARNING:   /usr/sbin
WARNING:   /usr/lib

WARNING: For recipe netbase, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/sbin

WARNING: For recipe systemd, the following files/directories were 
installed but not shipped in any package:
WARNING:   /usr/lib/binfmt.d
WARNING:   /usr/lib/sysctl.d
WARNING:   /usr/lib/modules-load.d

WARNING: For recipe linux-yocto, the following files/directories were 
installed but not shipped in any package:
WARNING:   /etc/modprobe.d
WARNING:   /lib/modules/3.0.8-yocto-standard+/modules.builtin
WARNING:   /lib/modules/3.0.8-yocto-standard+/modules.order
WARNING:   /lib/modules/3.0.8-yocto-standard+/build
WARNING:   /lib/modules/3.0.8-yocto-standard+/source

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/dongle_attach'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/irdaping'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/irda-utils-0.9.18-r0/packages-split/irda-utils/usr/sbin/irattach'

WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_io_debug'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_rid'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/hostap-utils-0.4.7-r4/packages-split/hostap-utils/usr/sbin/hostap_diag'
WARNING: QA Issue: No GNU_HASH in the elf binary: 
'/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/wireless-tools-1_29-r2/packages-split/libiw/usr/lib/libiw.so.29'

ERROR: Function 'useradd_sysroot' failed (see 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331 
for further information)
ERROR: Logfile of failure stored in: 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| ERROR: Function 'useradd_sysroot' failed (see 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/temp/log.do_install.30331 
for further information)
| + cd 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv5te-angstrom-linux-gnueabi/systemd-git-r6/git
| + useradd_sysroot
| + export 
PSEUDO=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo
| + 
PSEUDO=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo
| + export 
PSEUDO_LOCALSTATEDIR=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/var/pseudo
| + 
PSEUDO_LOCALSTATEDIR=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/var/pseudo
| + 
D=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm
| + useradd_preinst
| + OPT=
| + SYSROOT=
| + test 
x/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm 
'!=' x
| + 
SYSROOT=/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm
| + OPT='--root 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm'
| + GROUPADD_PARAM='-r lock'
| + USERADD_PARAM=
| + test 'x-r lock' '!=' x
| + echo 'Running groupadd commands...'
| Running groupadd commands...
| ++ echo '-r lock'
| ++ cut -d ';' -f 1
| + opts='-r lock'
| ++ echo '-r lock'
| ++ cut -d ';' -f 2-
| + remaining='-r lock'
| + test 'x-r lock' '!=' x
| ++ echo '-r lock'
| ++ awk '{ print $NF }'
| + groupname=lock
| ++ grep '^lock:' 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm/etc/group
| ++ true
| + group_exists=
| + test x = x
| + eval 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo 
groupadd --root 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm 
-r lock
| ++ 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/i686-linux/usr/bin/pseudo 
groupadd --root 
/home/ulf/projects/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm 
-r lock
| groupadd: cannot lock /etc/group; try again later.
NOTE: package systemd-git-r6: task do_install: Failed
ERROR: Task 158 
(/home/ulf/projects/OE_core/setup-scripts/sources/meta-openembedded/meta-oe/recipes-core/systemd/systemd_git.bb, 
do_install) failed with exit code '1'


-- 
Best Regards
Ulf Samuelsson
eMagii


[-- Attachment #2: 0001-tzcode-Change-tarball-location.patch --]
[-- Type: text/x-patch, Size: 1284 bytes --]

From f0b388c34980d1c22d49a770a3968c4aed3fde98 Mon Sep 17 00:00:00 2001
From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
Date: Sat, 26 Nov 2011 09:15:20 +0100
Subject: [PATCH 1/2] tzcode: Change tarball location

Signed-off-by: Ulf Samuelsson <ulf.samuelsson@telia.com>
---
 meta-oe/recipes-extended/tzcode/tzcode-native.inc |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-extended/tzcode/tzcode-native.inc b/meta-oe/recipes-extended/tzcode/tzcode-native.inc
index b946e71..0c7c1ca 100644
--- a/meta-oe/recipes-extended/tzcode/tzcode-native.inc
+++ b/meta-oe/recipes-extended/tzcode/tzcode-native.inc
@@ -2,8 +2,8 @@ DESCRIPTION = "tzcode, timezone zoneinfo utils -- zic, zdump, tzselect"
 INC_PR = "r4"
 
 SRC_URI = " \
-        ftp://elsie.nci.nih.gov/pub/tzcode${PV}.tar.gz;name=tzcode-${PV};subdir=${BPN}-${PV} \
-        ftp://elsie.nci.nih.gov/pub/tzdata${TZDATA_PV}.tar.gz;name=tzdata-${TZDATA_PV};subdir=${BPN}-${PV} \
+        http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode-${PV};subdir=${BPN}-${PV} \
+        http://www.iana.org/time-zones/repository/releases/tzdata${TZDATA_PV}.tar.gz;name=tzdata-${TZDATA_PV};subdir=${BPN}-${PV} \
 	"
 
 inherit native
-- 
1.7.4.1


[-- Attachment #3: 0002-tzdata-Change-tarball-location.patch --]
[-- Type: text/x-patch, Size: 1220 bytes --]

From 7c6dc15fe61b367a32324959036488059d130722 Mon Sep 17 00:00:00 2001
From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
Date: Sat, 26 Nov 2011 09:15:57 +0100
Subject: [PATCH 2/2] tzdata: Change tarball location

Signed-off-by: Ulf Samuelsson <ulf.samuelsson@telia.com>
---
 meta-oe/recipes-extended/tzdata/tzdata.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-oe/recipes-extended/tzdata/tzdata.inc b/meta-oe/recipes-extended/tzdata/tzdata.inc
index ceec924..9192d9b 100644
--- a/meta-oe/recipes-extended/tzdata/tzdata.inc
+++ b/meta-oe/recipes-extended/tzdata/tzdata.inc
@@ -11,7 +11,7 @@ RCONFLICTS_${PN} = "timezones timezone-africa timezone-america timezone-antarcti
              timezone-australia timezone-europe timezone-indian \
              timezone-iso3166.tab timezone-pacific timezone-zone.tab"
 
-SRC_URI = "ftp://elsie.nci.nih.gov/pub/tzdata${PV}.tar.gz;subdir=${BPN}-${PV}"
+SRC_URI = "http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;subdir=${BPN}-${PV}"
 
 TZONES= "africa antarctica asia australasia europe northamerica southamerica  \
          factory solar87 solar88 solar89 etcetera backward systemv \
-- 
1.7.4.1

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Eric Bénard]

Hi Ulf,

Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
> 3. When I ran into this problem, I exited with ctrl-C.
> This left some recipes in the middle of a fetch ,and the build could not
> continue.
> I had to "bitbake -c clean <package>" on all problematic packages to recover.
> Seems a little bit fragile to me.
>
already met here : you must let bitbake end the other tasks already started to 
prevent that (so only one control C).

> 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
> Fails in the fetch stage.
> I removed the layer, since it was not needed for qemuarm.
>
I also met this kind of problem. To prevent that problem, in my bsp overlay, I 
always add COMPATIBLE_MACHINE = "" to the machine specific recipes.
What is strange is that meta-ti also have this in its recipes so their 
linux-3.0 recipe should not be used if you target qemuarm.

> 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host)
> tiff won't build.
> Did:
> bitbake console-image"
> bitbake -c clean tiff
> bitbake tiff
> - No luck
> Reading through the mailing list, I found someone which deleted
> $TMPDIR and then
> bitbake tiff
> bitbake console-image
> That worked for me as well once, second time, same problem.
> Problem is that #include <iostream> fails.
>
> I noted that "iostream" is built and available in <sysroot>/usr/include/c++
> On the host, it is located in /usr/incolude/c++/<version>
> "tiff" build seems to be OK with Ubuntu 11.04 i686.
>
what is your BB_NUMBER_THREADS setting ?
Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I 
set it over 4, I often (always with a value of 8) meet problems with c++ 
includes during build from scratch. 4 seems the magic value which never 
trigger the problem.

Eric

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

On 2011-11-26 13:38, Eric Bénard wrote:
> Hi Ulf,
>
> Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
>> 3. When I ran into this problem, I exited with ctrl-C.
>> This left some recipes in the middle of a fetch ,and the build could not
>> continue.
>> I had to "bitbake -c clean <package>" on all problematic packages to 
>> recover.
>> Seems a little bit fragile to me.
>>
> already met here : you must let bitbake end the other tasks already 
> started to prevent that (so only one control C).
>
>> 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
>> Fails in the fetch stage.
>> I removed the layer, since it was not needed for qemuarm.
>>
> I also met this kind of problem. To prevent that problem, in my bsp 
> overlay, I always add COMPATIBLE_MACHINE = "" to the machine specific 
> recipes.
> What is strange is that meta-ti also have this in its recipes so their 
> linux-3.0 recipe should not be used if you target qemuarm.
>
>> 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host)
>> tiff won't build.
>> Did:
>> bitbake console-image"
>> bitbake -c clean tiff
>> bitbake tiff
>> - No luck
>> Reading through the mailing list, I found someone which deleted
>> $TMPDIR and then
>> bitbake tiff
>> bitbake console-image
>> That worked for me as well once, second time, same problem.
>> Problem is that #include <iostream> fails.
>>
>> I noted that "iostream" is built and available in 
>> <sysroot>/usr/include/c++
>> On the host, it is located in /usr/incolude/c++/<version>
>> "tiff" build seems to be OK with Ubuntu 11.04 i686.
>>
> what is your BB_NUMBER_THREADS setting ?
> Here (on 2 different hosts/distro/arch but with an i7 CPU in both 
> cases) if I set it over 4, I often (always with a value of 8) meet 
> problems with c++ includes during build from scratch. 4 seems the 
> magic value which never trigger the problem.

OK, it is higher than that.
Was trying out a Core-i7-980X with 6 cores/12 threads with TMP on a fast 
SSD.
The CPU seems to be running at low frequencies most of the time.


>
> Eric
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote:
> Hi Ulf,
> 
> Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
> > 3. When I ran into this problem, I exited with ctrl-C.
> > This left some recipes in the middle of a fetch ,and the build could not
> > continue.
> > I had to "bitbake -c clean <package>" on all problematic packages to recover.
> > Seems a little bit fragile to me.
> >
> already met here : you must let bitbake end the other tasks already started to 
> prevent that (so only one control C).
> 
> > 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
> > Fails in the fetch stage.
> > I removed the layer, since it was not needed for qemuarm.
> >
> I also met this kind of problem. To prevent that problem, in my bsp overlay, I 
> always add COMPATIBLE_MACHINE = "" to the machine specific recipes.
> What is strange is that meta-ti also have this in its recipes so their 
> linux-3.0 recipe should not be used if you target qemuarm.
> 
> > 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host)
> > tiff won't build.
> > Did:
> > bitbake console-image"
> > bitbake -c clean tiff
> > bitbake tiff
> > - No luck
> > Reading through the mailing list, I found someone which deleted
> > $TMPDIR and then
> > bitbake tiff
> > bitbake console-image
> > That worked for me as well once, second time, same problem.
> > Problem is that #include <iostream> fails.
> >
> > I noted that "iostream" is built and available in <sysroot>/usr/include/c++
> > On the host, it is located in /usr/incolude/c++/<version>
> > "tiff" build seems to be OK with Ubuntu 11.04 i686.
> >
> what is your BB_NUMBER_THREADS setting ?
> Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I 
> set it over 4, I often (always with a value of 8) meet problems with c++ 
> includes during build from scratch. 4 seems the magic value which never 
> trigger the problem.

To help me get further data points on this issue, are you using rm_work?
Do the recent changes in master help (the bitbake sstate/task_skip()
ones in particular)? I've not been able to reproduce this :(

Cheers,

Richard

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Eric Bénard]

Le 27/11/2011 12:40, Richard Purdie a écrit :
> On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote:
>> Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
>>> I noted that "iostream" is built and available in<sysroot>/usr/include/c++
>>> On the host, it is located in /usr/incolude/c++/<version>
>>> "tiff" build seems to be OK with Ubuntu 11.04 i686.
>>>
>> what is your BB_NUMBER_THREADS setting ?
>> Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I
>> set it over 4, I often (always with a value of 8) meet problems with c++
>> includes during build from scratch. 4 seems the magic value which never
>> trigger the problem.
>
> To help me get further data points on this issue, are you using rm_work?
> Do the recent changes in master help (the bitbake sstate/task_skip()
> ones in particular)? I've not been able to reproduce this :(
>
yes that was with rm_work, I still need to test with current head.

Eric

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

2011-11-27 12:47, Eric Bénard skrev:
> Le 27/11/2011 12:40, Richard Purdie a écrit :
>> On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote:
>>> Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
>>>> I noted that "iostream" is built and available 
>>>> in<sysroot>/usr/include/c++
>>>> On the host, it is located in /usr/incolude/c++/<version>
>>>> "tiff" build seems to be OK with Ubuntu 11.04 i686.
>>>>
>>> what is your BB_NUMBER_THREADS setting ?
>>> Here (on 2 different hosts/distro/arch but with an i7 CPU in both 
>>> cases) if I
>>> set it over 4, I often (always with a value of 8) meet problems with 
>>> c++
>>> includes during build from scratch. 4 seems the magic value which never
>>> trigger the problem.
>>
>> To help me get further data points on this issue, are you using rm_work?
>> Do the recent changes in master help (the bitbake sstate/task_skip()
>> ones in particular)? I've not been able to reproduce this :(
>>
> yes that was with rm_work, I still need to test with current head.
>
> Eric

I have tried Ubuntu 11.10 x64 once more.
This time with
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "j4".

Not exactly the same symptoms , but similar.
This time, the "string" header is not found.


| #    source='libcg_ba.cpp' object='libcg_ba.o' libtool=no
| arm-angstrom-linux-gnueabi-g++  -march=armv5te  -mno-thumb 
-mthumb-interwork  -mtune=arm926ej-s -mthumb-interwork -mno-thumb 
--sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm 
-DHAVE_CONFIG_H -I. -I.. -I../include    -O2 -pipe -g 
-feliminate-unused-debug-types -fpermissive -fvisibility-inlines-hidden 
-fvisibility-inlines-hidden -c -o libcg_ba.o libcg_ba.cpp
| libcg_ba.cpp:18:18: fatal error: string: No such file or directory
| compilation terminated.
| make[2]: *** [libcg_ba.o] Error 1

Tried compiling manually.
It appears to me that the "--sysroot" directive gets ignored.

--sysroot=/media/SSD/OE_core/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/qemuarm

I manually added "-I/usr/include/c++", but that did not help
I then copied "string" to the compile directory, and then the
compile continued /until missing the next include file)


compiler built:
arm-angstrom-linux-gnueabi-g++ --version
arm-angstrom-linux-gnueabi-g++ (GCC) 4.5.4 20110917 (prerelease)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


The same build works on Ubuntu 11.04 i686.

Best Regards
Ulf Samuelsson
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Eric Bénard]

Le 27/11/2011 12:40, Richard Purdie a écrit :
> To help me get further data points on this issue, are you using rm_work?
> Do the recent changes in master help (the bitbake sstate/task_skip()
> ones in particular)? I've not been able to reproduce this :(
>
OK I don't seem to reproduce it with head (but I now meet a new problem with 
base-passwd, see coming mail).

Eric

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote:
> Downloaded the latest, and tried building console-image for qemuarm.
> Host = Ubuntu 11.04 i686.
> 
> Looked through the build log, and thought I'd share it with the list.

Thanks for doing this, its valuable feedback.

> A number of warnings (see below)

We're trying to work through addressing those. Some of them are from
versions in meta-oe where there is a fix for the error in OECore (such
as the libgcc linker hash style).

> Seen a couple of errors as well.
> 
> 1.    ERROR: Function 'useradd_sysroot' failed
>          Tried to access "/etc/group" but this was locked.
>          Problem disappeared the next time I rebuilt.

Can you file a bug about this problem please. I think we need to go
through the code paths in shadow and ensure its locking is sane. I took
a quick look at the code and was left wondering what lckpwdf() does for
example. Scott, could you take a look at this?

> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer 
> available.
>          tzdata , same problem.
>          The recipe is located in two places.
>          meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the 
> problem
>          This is what the build uses.

This is something to raise with the meta-oe maintainers. I think there
isn't a problem in OECore.

> 3.    When I ran into this problem, I exited with ctrl-C.
>          This left some recipes in the middle of a fetch ,and the build 
> could not continue.
>          I had to "bitbake -c clean <package>" on all problematic 
> packages to recover.
>          Seems a little bit fragile to me.

Yes, this isn't good. Could you file a bug report on this please?

> 4.     linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
>          Fails in the fetch stage.
>          I removed the layer, since it was not needed for qemuarm.

Makes sense and its something raise with the meta-ti layer maintainers
which I think I've seen elsewhere.

> 5.    When compiling on a Ubuntu 11.10 x64 host  (linux 3.x host)
>          tiff won't build.
>          Did:
>              bitbake console-image"
>              bitbake -c clean tiff
>              bitbake  tiff
>          - No luck
>          Reading through the mailing list, I found someone which deleted
>          $TMPDIR and then
>              bitbake tiff
>              bitbake console-image
>          That worked for me as well once, second time, same problem.
>          Problem is that #include <iostream> fails.
> 
>          I noted that "iostream" is built and available in 
> <sysroot>/usr/include/c++
>          On the host, it is located in /usr/incolude/c++/<version>
>          "tiff" build seems to be OK with Ubuntu 11.04 i686.

I think these errors should be fixed by recent changes. If not I'd be
interested in the full console log please.

Cheers,

Richard

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Koen Kooi]

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


Op 29 nov. 2011, om 16:03 heeft Richard Purdie het volgende geschreven:

> On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote:
>> Downloaded the latest, and tried building console-image for qemuarm.
>> Host = Ubuntu 11.04 i686.
>> 
>> Looked through the build log, and thought I'd share it with the list.
> 
> Thanks for doing this, its valuable feedback.
> 
>> A number of warnings (see below)
> 
> We're trying to work through addressing those. Some of them are from
> versions in meta-oe where there is a fix for the error in OECore (such
> as the libgcc linker hash style).

Assuming your statement is true, why isn't the hash style fixed in the .inc? Meta-oe uses the ones from OE-core, so if the include files are sane, the toolchain for meta-oe is sane.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Tue, 2011-11-29 at 16:50 +0100, Koen Kooi wrote:
> Op 29 nov. 2011, om 16:03 heeft Richard Purdie het volgende geschreven:
> 
> > On Sat, 2011-11-26 at 12:24 +0100, Ulf Samuelsson wrote:
> >> Downloaded the latest, and tried building console-image for qemuarm.
> >> Host = Ubuntu 11.04 i686.
> >> 
> >> Looked through the build log, and thought I'd share it with the list.
> > 
> > Thanks for doing this, its valuable feedback.
> > 
> >> A number of warnings (see below)
> > 
> > We're trying to work through addressing those. Some of them are from
> > versions in meta-oe where there is a fix for the error in OECore (such
> > as the libgcc linker hash style).
> 
> Assuming your statement is true, why isn't the hash style fixed in
> the .inc? Meta-oe uses the ones from OE-core, so if the include files
> are sane, the toolchain for meta-oe is sane.

Its fixed by a patch so someone needs to backport that patch to the gcc
4.5 patch set.

Cheers,

Richard

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

On 2011-11-29 16:03, Richard Purdie wrote:
>
>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>> available.
>>           tzdata , same problem.
>>           The recipe is located in two places.
>>           meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>> problem
>>           This is what the build uses.
> This is something to raise with the meta-oe maintainers. I think there
> isn't a problem in OECore.

Since we now have a large number of layers, maybe it is a good
idea to define in each layer,  how the "git send email" should behave in
by providing a better ".git/config" file in the trunk?


I.E:

[sendemail]
     to = openembedded-core@lists.openembedded.org

or
meta-angstrom/.git/config
[sendemail]
     to = angstrom-distro-devel@linuxtogo.org
[format]
     subjectprefix = "[meta-angstrom]"


No need to look in the README file with this.


-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Koen Kooi]

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


Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:

> On 2011-11-29 16:03, Richard Purdie wrote:
>> 
>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>>> available.
>>>          tzdata , same problem.
>>>          The recipe is located in two places.
>>>          meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>> problem
>>>          This is what the build uses.
>> This is something to raise with the meta-oe maintainers. I think there
>> isn't a problem in OECore.
> 
> Since we now have a large number of layers, maybe it is a good
> idea to define in each layer,  how the "git send email" should behave in
> by providing a better ".git/config" file in the trunk?
> 
> 
> I.E:
> 
> [sendemail]
>    to = openembedded-core@lists.openembedded.org
> 
> or
> meta-angstrom/.git/config
> [sendemail]
>    to = angstrom-distro-devel@linuxtogo.org
> [format]
>    subjectprefix = "[meta-angstrom]"
> 
> 
> No need to look in the README file with this.

That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

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

On 2011-11-29 21:06, Koen Kooi wrote:
> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>
>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>>>> available.
>>>>           tzdata , same problem.
>>>>           The recipe is located in two places.
>>>>           meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>> problem
>>>>           This is what the build uses.
>>> This is something to raise with the meta-oe maintainers. I think there
>>> isn't a problem in OECore.
>> Since we now have a large number of layers, maybe it is a good
>> idea to define in each layer,  how the "git send email" should behave in
>> by providing a better ".git/config" file in the trunk?
>>
>>
>> I.E:
>>
>> [sendemail]
>>     to = openembedded-core@lists.openembedded.org
>>
>> or
>> meta-angstrom/.git/config
>> [sendemail]
>>     to = angstrom-distro-devel@linuxtogo.org
>> [format]
>>     subjectprefix = "[meta-angstrom]"
>>
>>
>> No need to look in the README file with this.
> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
Not really.
Even if pulling is the preferred way for certain layers,
having this in the config, wouldnt hurt a pulling process.

It does makes it more likely that stuff is not sent to the wrong list.

BR
Ulf Samuelsson

>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Best Regards
Ulf Samuelsson
eMagii


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

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

>> Seen a couple of errors as well.
>>
>> 1.    ERROR: Function 'useradd_sysroot' failed
>>           Tried to access "/etc/group" but this was locked.
>>           Problem disappeared the next time I rebuilt.
> Can you file a bug about this problem please. I think we need to go
> through the code paths in shadow and ensure its locking is sane. I took
> a quick look at the code and was left wondering what lckpwdf() does for
> example. Scott, could you take a look at this?

Bugzilla is out of service, so bugs cannot be filed.

Haven't seen the issue since then so it is hard to give any details.
I used very high BB_NUMBER_THREADS = 24.

This machine (Ubuntu 11.10 /x64) gets stuck in building C++
programs at the moment, so I am considering resinstalling with
Ubuntu 11.04 to get something done.


-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Scott Garman]

On 11/29/2011 01:18 PM, Ulf Samuelsson wrote:
>
>>> Seen a couple of errors as well.
>>>
>>> 1. ERROR: Function 'useradd_sysroot' failed
>>> Tried to access "/etc/group" but this was locked.
>>> Problem disappeared the next time I rebuilt.
>> Can you file a bug about this problem please. I think we need to go
>> through the code paths in shadow and ensure its locking is sane. I took
>> a quick look at the code and was left wondering what lckpwdf() does for
>> example. Scott, could you take a look at this?
>
> Bugzilla is out of service, so bugs cannot be filed.

I have filed a bug for this, and have been trying to reproduce it 
without success:

http://bugzilla.pokylinux.org/show_bug.cgi?id=1794

> Haven't seen the issue since then so it is hard to give any details.
> I used very high BB_NUMBER_THREADS = 24.

I do have access to a system with a lot of cores, and have been doing 
builds on it.

I'd just like to confirm that when you saw this, it was a build from 
scratch (e.g, not using sstate cache from a previous build). And also, 
you *weren't* building this from a remote filesystem (NFS), correct?

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Khem Raj]

On (29/11/11 16:03), Richard Purdie wrote:
> > Assuming your statement is true, why isn't the hash style fixed in
> > the .inc? Meta-oe uses the ones from OE-core, so if the include files
> > are sane, the toolchain for meta-oe is sane.
> 
> Its fixed by a patch so someone needs to backport that patch to the gcc
> 4.5 patch set.

I have intentionally not ported the patch back to 4.5 but let me see if
I can find some spare hours

-Khem

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Wed, 2011-11-30 at 17:52 -0800, Khem Raj wrote:
> On (29/11/11 16:03), Richard Purdie wrote:
> > > Assuming your statement is true, why isn't the hash style fixed in
> > > the .inc? Meta-oe uses the ones from OE-core, so if the include files
> > > are sane, the toolchain for meta-oe is sane.
> > 
> > Its fixed by a patch so someone needs to backport that patch to the gcc
> > 4.5 patch set.
> 
> I have intentionally not ported the patch back to 4.5 but let me see if
> I can find some spare hours

Don't take my comments as a request to do so btw, personally speaking I
don't see it as a problem. I just wanted to be clear about what was
missing.

Cheers,

Richard

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Philip Balister]

On 11/29/2011 03:06 PM, Koen Kooi wrote:
> 
> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
> 
>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>
>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>>>> available.
>>>>          tzdata , same problem.
>>>>          The recipe is located in two places.
>>>>          meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>> problem
>>>>          This is what the build uses.
>>> This is something to raise with the meta-oe maintainers. I think there
>>> isn't a problem in OECore.
>>
>> Since we now have a large number of layers, maybe it is a good
>> idea to define in each layer,  how the "git send email" should behave in
>> by providing a better ".git/config" file in the trunk?
>>
>>
>> I.E:
>>
>> [sendemail]
>>    to = openembedded-core@lists.openembedded.org
>>
>> or
>> meta-angstrom/.git/config
>> [sendemail]
>>    to = angstrom-distro-devel@linuxtogo.org
>> [format]
>>    subjectprefix = "[meta-angstrom]"
>>
>>
>> No need to look in the README file with this.
> 
> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers

Even if it is not the preferred way, it would direct the discussion to
the appropriate list. This would reduce the number of mis-directed
emails to this list.

And we know that no one reads the README's :)

Philip

> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

On 2011-11-30 18:30, Scott Garman wrote:
> On 11/29/2011 01:18 PM, Ulf Samuelsson wrote:
>>
>>>> Seen a couple of errors as well.
>>>>
>>>> 1. ERROR: Function 'useradd_sysroot' failed
>>>> Tried to access "/etc/group" but this was locked.
>>>> Problem disappeared the next time I rebuilt.
>>> Can you file a bug about this problem please. I think we need to go
>>> through the code paths in shadow and ensure its locking is sane. I took
>>> a quick look at the code and was left wondering what lckpwdf() does for
>>> example. Scott, could you take a look at this?
>>
>> Bugzilla is out of service, so bugs cannot be filed.
>
> I have filed a bug for this, and have been trying to reproduce it 
> without success:
>
> http://bugzilla.pokylinux.org/show_bug.cgi?id=1794
>
>> Haven't seen the issue since then so it is hard to give any details.
>> I used very high BB_NUMBER_THREADS = 24.
>
> I do have access to a system with a lot of cores, and have been doing 
> builds on it.
>
> I'd just like to confirm that when you saw this, it was a build from 
> scratch (e.g, not using sstate cache from a previous build). And also, 
> you *weren't* building this from a remote filesystem (NFS), correct?
>
> Thanks,
>
> Scott
>
No NFS for sure.

I think this was the first build, but only 99% sure.
It disappered when I restarted the build.

Have not seen this problem repeated, but then, the build on this
machine has other problems

Packages tend to fail since the c++ compiler seems to ignore "--sysroot"

Machine = Ubuntu-11.10 x64.

This is with BB_NUMBER_THREADS = "4"
If I change this, then the same problem occur, but in a different package.
(Tried with "4" AND "24")

BR
Ulf



-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Koen Kooi]

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


Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven:

> On 11/29/2011 03:06 PM, Koen Kooi wrote:
>> 
>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>> 
>>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>> 
>>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>>>>> available.
>>>>>         tzdata , same problem.
>>>>>         The recipe is located in two places.
>>>>>         meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>>> problem
>>>>>         This is what the build uses.
>>>> This is something to raise with the meta-oe maintainers. I think there
>>>> isn't a problem in OECore.
>>> 
>>> Since we now have a large number of layers, maybe it is a good
>>> idea to define in each layer,  how the "git send email" should behave in
>>> by providing a better ".git/config" file in the trunk?
>>> 
>>> 
>>> I.E:
>>> 
>>> [sendemail]
>>>   to = openembedded-core@lists.openembedded.org
>>> 
>>> or
>>> meta-angstrom/.git/config
>>> [sendemail]
>>>   to = angstrom-distro-devel@linuxtogo.org
>>> [format]
>>>   subjectprefix = "[meta-angstrom]"
>>> 
>>> 
>>> No need to look in the README file with this.
>> 
>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
> 
> Even if it is not the preferred way, it would direct the discussion to
> the appropriate list. This would reduce the number of mis-directed
> emails to this list.

You can't fix stupid, sadly.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

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

2011-12-01 16:37, Koen Kooi skrev:
> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven:
>
>> On 11/29/2011 03:06 PM, Koen Kooi wrote:
>>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>>>
>>>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" is no longer
>>>>>> available.
>>>>>>          tzdata , same problem.
>>>>>>          The recipe is located in two places.
>>>>>>          meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>>>> problem
>>>>>>          This is what the build uses.
>>>>> This is something to raise with the meta-oe maintainers. I think there
>>>>> isn't a problem in OECore.
>>>> Since we now have a large number of layers, maybe it is a good
>>>> idea to define in each layer,  how the "git send email" should behave in
>>>> by providing a better ".git/config" file in the trunk?
>>>>
>>>>
>>>> I.E:
>>>>
>>>> [sendemail]
>>>>    to = openembedded-core@lists.openembedded.org
>>>>
>>>> or
>>>> meta-angstrom/.git/config
>>>> [sendemail]
>>>>    to = angstrom-distro-devel@linuxtogo.org
>>>> [format]
>>>>    subjectprefix = "[meta-angstrom]"
>>>>
>>>>
>>>> No need to look in the README file with this.
>>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
>> Even if it is not the preferred way, it would direct the discussion to
>> the appropriate list. This would reduce the number of mis-directed
>> emails to this list.
> You can't fix stupid, sadly.

Tend to disagree.
The whole purpose of OE is to make it possible for people,
stupid or not, to go off and make things which they would
not be able to do on their own.

As I see it, it is no real drawback of adding this, and at least some 
benefit.

As for not beeing the preferred way, I think that people that engage 
themselves
in a layer should adopt the preferred way.

Anyone seeing a bad layer, applicable only to a small subset of users,
interfering with their build should not be expected
to put a lof of effort into the fix, except reporting it.
Then the mailing list is probably the easiest thing to use.

If this is not there, expect them to send it to the official list.
BR
Ulf


>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
Best Regards
Ulf Samuelsson
eMagii


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

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Frans Meulenbroeks]

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

2011/12/1 Ulf Samuelsson <openembedded-core@emagii.com>

>  2011-12-01 16:37, Koen Kooi skrev:
>
> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven:
>
>
>  On 11/29/2011 03:06 PM, Koen Kooi wrote:
>
>  Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>
>
>  On 2011-11-29 16:03, Richard Purdie wrote:
>
>   2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz" <ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz> is no longer
> available.
>         tzdata , same problem.
>         The recipe is located in two places.
>         meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
> problem
>         This is what the build uses.
>
>  This is something to raise with the meta-oe maintainers. I think there
> isn't a problem in OECore.
>
>  Since we now have a large number of layers, maybe it is a good
> idea to define in each layer,  how the "git send email" should behave in
> by providing a better ".git/config" file in the trunk?
>
>
> I.E:
>
> [sendemail]
>   to = openembedded-core@lists.openembedded.org
>
> or
> meta-angstrom/.git/config
> [sendemail]
>   to = angstrom-distro-devel@linuxtogo.org
> [format]
>   subjectprefix = "[meta-angstrom]"
>
>
> No need to look in the README file with this.
>
>  That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
>
>  Even if it is not the preferred way, it would direct the discussion to
> the appropriate list. This would reduce the number of mis-directed
> emails to this list.
>
>  You can't fix stupid, sadly.
>
>
> Tend to disagree.
> The whole purpose of OE is to make it possible for people,
> stupid or not, to go off and make things which they would
> not be able to do on their own.
>
> As I see it, it is no real drawback of adding this, and at least some
> benefit.
>
> As for not beeing the preferred way, I think that people that engage
> themselves
> in a layer should adopt the preferred way.
>
> Anyone seeing a bad layer, applicable only to a small subset of users,
> interfering with their build should not be expected
> to put a lof of effort into the fix, except reporting it.
> Then the mailing list is probably the easiest thing to use.
>
> If this is not there, expect them to send it to the official list.
> BR
> Ulf
>

My two cents:
If I see a small problem in a layer that I am not working on and submitting
a patch is easy (e.g. committing the patch, doing a send-email) I would
probably do so.
If it becomes harder (since I have to find what list it needs to be send
to) chances that the effort is made become smaller and actually depending
on the time at hand
If i have to set up a git mirror just for this single patch, forget it.

I think if we want to encourage people fixing and submitting patches it
helps to have a mailing address in the config file.
But of course if you prefer to do maintenance only with the happy few, this
is less desirable (but then you should probably consider not accepting
mailed patches at all)

frans

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

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Koen Kooi]

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


Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven:

> 2011-12-01 16:37, Koen Kooi skrev:
>> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven:
>> 
>> 
>>> On 11/29/2011 03:06 PM, Koen Kooi wrote:
>>> 
>>>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>>>> 
>>>> 
>>>>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>>> 
>>>>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz"
>>>>>>>  is no longer
>>>>>>> available.
>>>>>>>         tzdata , same problem.
>>>>>>>         The recipe is located in two places.
>>>>>>>         meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>>>>> problem
>>>>>>>         This is what the build uses.
>>>>>>> 
>>>>>> This is something to raise with the meta-oe maintainers. I think there
>>>>>> isn't a problem in OECore.
>>>>>> 
>>>>> Since we now have a large number of layers, maybe it is a good
>>>>> idea to define in each layer,  how the "git send email" should behave in
>>>>> by providing a better ".git/config" file in the trunk?
>>>>> 
>>>>> 
>>>>> I.E:
>>>>> 
>>>>> [sendemail]
>>>>>   to = 
>>>>> openembedded-core@lists.openembedded.org
>>>>> 
>>>>> 
>>>>> or
>>>>> meta-angstrom/.git/config
>>>>> [sendemail]
>>>>>   to = 
>>>>> angstrom-distro-devel@linuxtogo.org
>>>>> 
>>>>> [format]
>>>>>   subjectprefix = "[meta-angstrom]"
>>>>> 
>>>>> 
>>>>> No need to look in the README file with this.
>>>>> 
>>>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
>>>> 
>>> Even if it is not the preferred way, it would direct the discussion to
>>> the appropriate list. This would reduce the number of mis-directed
>>> emails to this list.
>>> 
>> You can't fix stupid, sadly.
>> 
> 
> Tend to disagree.
> The whole purpose of OE is to make it possible for people,
> stupid or not, to go off and make things which they would
> not be able to do on their own.
> 
> As I see it, it is no real drawback of adding this, and at least some benefit.

The drawback is that people will postpone reading the README even longer.

Why are you so dead against having people read the README?

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

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

On 2011-12-02 10:49, Koen Kooi wrote:
> Op 1 dec. 2011, om 17:31 heeft Ulf Samuelsson het volgende geschreven:
>
>> 2011-12-01 16:37, Koen Kooi skrev:
>>> Op 1 dec. 2011, om 14:16 heeft Philip Balister het volgende geschreven:
>>>
>>>
>>>> On 11/29/2011 03:06 PM, Koen Kooi wrote:
>>>>
>>>>> Op 29 nov. 2011, om 20:36 heeft Ulf Samuelsson het volgende geschreven:
>>>>>
>>>>>
>>>>>> On 2011-11-29 16:03, Richard Purdie wrote:
>>>>>>
>>>>>>>> 2.    "ftp://elsie.nci.nih.gov/pub/tzcode2011i.tar.gz"
>>>>>>>>   is no longer
>>>>>>>> available.
>>>>>>>>          tzdata , same problem.
>>>>>>>>          The recipe is located in two places.
>>>>>>>>          meta-openembedded/meta-oe/recipes-extended/tz*/tz*.bb have the
>>>>>>>> problem
>>>>>>>>          This is what the build uses.
>>>>>>>>
>>>>>>> This is something to raise with the meta-oe maintainers. I think there
>>>>>>> isn't a problem in OECore.
>>>>>>>
>>>>>> Since we now have a large number of layers, maybe it is a good
>>>>>> idea to define in each layer,  how the "git send email" should behave in
>>>>>> by providing a better ".git/config" file in the trunk?
>>>>>>
>>>>>>
>>>>>> I.E:
>>>>>>
>>>>>> [sendemail]
>>>>>>    to =
>>>>>> openembedded-core@lists.openembedded.org
>>>>>>
>>>>>>
>>>>>> or
>>>>>> meta-angstrom/.git/config
>>>>>> [sendemail]
>>>>>>    to =
>>>>>> angstrom-distro-devel@linuxtogo.org
>>>>>>
>>>>>> [format]
>>>>>>    subjectprefix = "[meta-angstrom]"
>>>>>>
>>>>>>
>>>>>> No need to look in the README file with this.
>>>>>>
>>>>> That assumes git-send-email is the preferred way, which it isn;'t for a lot of layers
>>>>>
>>>> Even if it is not the preferred way, it would direct the discussion to
>>>> the appropriate list. This would reduce the number of mis-directed
>>>> emails to this list.
>>>>
>>> You can't fix stupid, sadly.
>>>
>> Tend to disagree.
>> The whole purpose of OE is to make it possible for people,
>> stupid or not, to go off and make things which they would
>> not be able to do on their own.
>>
>> As I see it, it is no real drawback of adding this, and at least some benefit.
> The drawback is that people will postpone reading the README even longer.
>
> Why are you so dead against having people read the README?
I am against that every layer should *appear to* have their own way of 
treating feedback.

There should be a common README on how to provide a patch, and any
difference in where it ends up should be hidden in the system.
This will make it easy for the causal user of a layer.

If you want stuff to be pulled, then there are ways of handling this.
Instead of directing the email to a list, you could direct the mail
to a special address, which bounces back a message saying that
the recommended thing is to pull.
It could of course forward to the real list as well.

As mentioned before by me, and by Frans right now, If I have to set up a 
git mirror
for something I dont use (like meta-ti right now),
just because this has a problem which affects my builds, I won't do that.
As I dig deeper into openembedded-core, I will probably get
to setting up git mirrors for the layers I use.
OTOH , If I am bored and pull up my Beagleboard from a drawer, again
I would probably do a git mirror for meta-ti.

Some further study shows that the idea will not work as intended fully.
meta-openembedded and meta-handhelds have "meta-*" subdirectories
which each have their own README with different instructions for the 
same git tree.
Seems kind of strange to me.


BR
Ulf Samuelsson

>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Best Regards
Ulf Samuelsson
eMagii


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

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

On 2011-12-01 15:49, Ulf Samuelsson wrote:
> On 2011-11-30 18:30, Scott Garman wrote:
>> On 11/29/2011 01:18 PM, Ulf Samuelsson wrote:
>>>
>>>>> Seen a couple of errors as well.
>>>>>
>>>>> 1. ERROR: Function 'useradd_sysroot' failed
>>>>> Tried to access "/etc/group" but this was locked.
>>>>> Problem disappeared the next time I rebuilt.
>>>> Can you file a bug about this problem please. I think we need to go
>>>> through the code paths in shadow and ensure its locking is sane. I 
>>>> took
>>>> a quick look at the code and was left wondering what lckpwdf() does 
>>>> for
>>>> example. Scott, could you take a look at this?
>>>
>>> Bugzilla is out of service, so bugs cannot be filed.
>>
>> I have filed a bug for this, and have been trying to reproduce it 
>> without success:
>>
>> http://bugzilla.pokylinux.org/show_bug.cgi?id=1794
>>
>>> Haven't seen the issue since then so it is hard to give any details.
>>> I used very high BB_NUMBER_THREADS = 24.
>>
>> I do have access to a system with a lot of cores, and have been doing 
>> builds on it.
>>
>> I'd just like to confirm that when you saw this, it was a build from 
>> scratch (e.g, not using sstate cache from a previous build). And 
>> also, you *weren't* building this from a remote filesystem (NFS), 
>> correct?
>>
>> Thanks,
>>
>> Scott
>>
> No NFS for sure.
>
> I think this was the first build, but only 99% sure.
> It disappered when I restarted the build.
>
> Have not seen this problem repeated, but then, the build on this
> machine has other problems
>
> Packages tend to fail since the c++ compiler seems to ignore "--sysroot"
>
> Machine = Ubuntu-11.10 x64.
>
> This is with BB_NUMBER_THREADS = "4"
> If I change this, then the same problem occur, but in a different 
> package.
> (Tried with "4" AND "24")
>
Have made some further tests with the same machine, but now running 
Ubuntu 11.04 x64

bitbake console-image

     PARALLEL_TASKS        BB_NUMBER_TASKS        BUILD TIME
     2                                  2                                
       1:24:16
     4                                  4                                
       0:48:22
     6                                  6                                
       0:45:00
     24                                24                                
     C++ compiler fails with --sysroot problem
                                                                         
         after ~2200 out of 2400 tasks.



BR
Ulf

-- 
Best Regards
Ulf Samuelsson
eMagii

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Henning Heinold]

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

On Sat, Dec 03, 2011 at 09:03:46PM +0100, Ulf Samuelsson wrote:
> Have made some further tests with the same machine, but now running
> Ubuntu 11.04 x64
> 
> bitbake console-image
> 
>     PARALLEL_TASKS        BB_NUMBER_TASKS        BUILD TIME
>     2                                  2
> 1:24:16
>     4                                  4
> 0:48:22
>     6                                  6
> 0:45:00
>     24                                24
> C++ compiler fails with --sysroot problem
>         after ~2200 out of 2400 tasks.
> 
> 
> 
> BR
> Ulf

Hi Ulf,

can you try the attached patch if it solves the problem?

Bye Henning

[-- Attachment #2: 0001-gcc-cross-attempt-fix-default-include-path-of-c.patch --]
[-- Type: text/x-diff, Size: 1083 bytes --]

From b96f4d6b73ff993910b635b9dca962fac8eeeb49 Mon Sep 17 00:00:00 2001
From: Henning Heinold <heinold@inf.fu-berlin.de>
Date: Sun, 4 Dec 2011 12:17:15 +0100
Subject: [PATCH] gcc-cross: attempt fix default include path of c++

---
 meta/recipes-devtools/gcc/gcc-configure-cross.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-configure-cross.inc b/meta/recipes-devtools/gcc/gcc-configure-cross.inc
index d2d9081..f42a6ee 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-cross.inc
@@ -9,7 +9,7 @@ EXTRA_OECONF += " --enable-poison-system-directories \
 
 INHIBIT_DEFAULT_DEPS = "1"
 
-EXTRA_OECONF_PATHS = "--with-local-prefix=${STAGING_DIR_TARGET}${target_exec_prefix} \
+EXTRA_OECONF_PATHS = "--with-local-prefix=${STAGING_DIR_TARGET} \
 		      --with-gxx-include-dir=${target_includedir}/c++ \
                       --with-sysroot=${STAGING_DIR_TARGET} \
                       --with-build-sysroot=${STAGING_DIR_TARGET}"
-- 
1.7.7.3

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Sun, 2011-12-04 at 12:20 +0100, Henning Heinold wrote:
> On Sat, Dec 03, 2011 at 09:03:46PM +0100, Ulf Samuelsson wrote:
> > Have made some further tests with the same machine, but now running
> > Ubuntu 11.04 x64
> > 
> > bitbake console-image
> > 
> >     PARALLEL_TASKS        BB_NUMBER_TASKS        BUILD TIME
> >     2                                  2
> > 1:24:16
> >     4                                  4
> > 0:48:22
> >     6                                  6
> > 0:45:00
> >     24                                24
> > C++ compiler fails with --sysroot problem
> >         after ~2200 out of 2400 tasks.
> > 
> > 
> > 
> > BR
> > Ulf
> 
> Hi Ulf,
> 
> can you try the attached patch if it solves the problem?

Can someone please explain to me how this would fix the problem?

If this were the issue shouldn't it either always work or always fail?

I'm worried that even if this does "fix" the problem, there is a deeper
issue lurking somewhere :(

Cheers,

Richard

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Khem Raj]

On (04/12/11 11:35), Richard Purdie wrote:
> On Sun, 2011-12-04 at 12:20 +0100, Henning Heinold wrote:
> > On Sat, Dec 03, 2011 at 09:03:46PM +0100, Ulf Samuelsson wrote:
> > > Have made some further tests with the same machine, but now running
> > > Ubuntu 11.04 x64
> > > 
> > > bitbake console-image
> > > 
> > >     PARALLEL_TASKS        BB_NUMBER_TASKS        BUILD TIME
> > >     2                                  2
> > > 1:24:16
> > >     4                                  4
> > > 0:48:22
> > >     6                                  6
> > > 0:45:00
> > >     24                                24
> > > C++ compiler fails with --sysroot problem
> > >         after ~2200 out of 2400 tasks.
> > > 
> > > 
> > > 
> > > BR
> > > Ulf
> > 
> > Hi Ulf,
> > 
> > can you try the attached patch if it solves the problem?

Does this really fix the problem.

> 
> Can someone please explain to me how this would fix the problem?
> 
> If this were the issue shouldn't it either always work or always fail?
> 
> I'm worried that even if this does "fix" the problem, there is a deeper
> issue lurking somewhere :(

We use --with-local-prefix and then also --with-gxx-include-dir which
points to /usr/include/c++ 

Now the documentation says that --with-gxx-include-dir is an absolute
path but if sysroot gets prepended to it or not I am not clear yet
if sysroot gets prepended to it then we should be in safe spot


> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Ulf Samuelsson]

On 2011-12-07 23:51, Khem Raj wrote:
> On (04/12/11 11:35), Richard Purdie wrote:
>> On Sun, 2011-12-04 at 12:20 +0100, Henning Heinold wrote:
>>> On Sat, Dec 03, 2011 at 09:03:46PM +0100, Ulf Samuelsson wrote:
>>>> Have made some further tests with the same machine, but now running
>>>> Ubuntu 11.04 x64
>>>>
>>>> bitbake console-image
>>>>
>>>>      PARALLEL_TASKS        BB_NUMBER_TASKS        BUILD TIME
>>>>      2                                  2
>>>> 1:24:16
>>>>      4                                  4
>>>> 0:48:22
>>>>      6                                  6
>>>> 0:45:00
>>>>      24                                24
>>>> C++ compiler fails with --sysroot problem
>>>>          after ~2200 out of 2400 tasks.
>>>>
>>>>
>>>>
>>>> BR
>>>> Ulf
>>> Hi Ulf,
>>>
>>> can you try the attached patch if it solves the problem?
> Does this really fix the problem.

It  apparently fixes the symptoms at least (but I didn't do many tests.
On the other hand, the performance improvement seems minimal
once your past 6-8, even on a hexa core machine.

>> Can someone please explain to me how this would fix the problem?
>>
>> If this were the issue shouldn't it either always work or always fail?
>>
>> I'm worried that even if this does "fix" the problem, there is a deeper
>> issue lurking somewhere :(
> We use --with-local-prefix and then also --with-gxx-include-dir which
> points to /usr/include/c++
>
> Now the documentation says that --with-gxx-include-dir is an absolute
> path but if sysroot gets prepended to it or not I am not clear yet
> if sysroot gets prepended to it then we should be in safe spot
>
>
>> Cheers,
>>
>> Richard
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


-- 
Best Regards
Ulf Samuelsson
eMagii