Skip to contentSkip to conversation

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

PATCH Ulf Samuelsson 9 participants 29 messages Nov 26, 2011 – Dec 7, 2011

lore
Share & tools
lore
#0 lore raw

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'

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii

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

---
 meta-oe/recipes-extended/tzcode/tzcode-native.inc |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta-oe/recipes-extended/tzcode/tzcode-native.inc +2 -2
index b946e71..0c7c1ca 100644
@@ -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
Signature · 1 line
1.7.4.1

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

---
 meta-oe/recipes-extended/tzdata/tzdata.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
meta-oe/recipes-extended/tzdata/tzdata.inc +1 -1
index ceec924..9192d9b 100644
@@ -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 \
Signature · 1 line
1.7.4.1
#1 lore raw

Hi Ulf,

Quoted 6 lines · Ulf Samuelsson

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

Quoted 4 lines

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.

Quoted 14 lines

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.

Quoted 4 lines

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

#2 lore raw
Quoted 32 lines · Eric Bénard

Hi Ulf,

Quoted 6 lines · Ulf Samuelsson

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

Quoted 4 lines

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.

Quoted 14 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 7 lines

Eric

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#3 lore raw
In reply to Eric Bénard
Quoted 39 lines · Eric Bénard

Hi Ulf,

Quoted 6 lines · Ulf Samuelsson

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

Quoted 4 lines

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.

Quoted 14 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

#4 lore raw
Quoted 12 lines · Richard Purdie
Quoted 10 lines · Eric Bénard
Quoted 4 lines · Ulf Samuelsson

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.

Quoted 4 lines

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

#5 lore raw

2011-11-27 12:47, Eric Bénard skrev:

Quoted 13 lines · Richard Purdie
Quoted 12 lines · Eric Bénard
Quoted 10 lines · Ulf Samuelsson
Quoted 4 lines

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.

Quoted 7 lines
Quoted 4 lines

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

Quoted 5 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#6 lore raw
In reply to Richard Purdie
Quoted 4 lines · Richard Purdie

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

#7 lore raw
In reply to Ulf Samuelsson
Quoted 4 lines · Ulf Samuelsson

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.

Quoted 1 line

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

Quoted 5 lines

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?

Quoted 7 lines

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.

Quoted 6 lines

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?

Quoted 3 lines

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.

Quoted 14 lines

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.

Quoted 4 lines

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

#8 lore raw

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

Quoted 6 lines · Ulf Samuelsson
Quoted 4 lines

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.

Quoted 7 lines

Thanks for doing this, its valuable feedback.

Quoted 1 line

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.

#9 lore raw
Quoted 12 lines · Koen Kooi

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

Quoted 10 lines · Ulf Samuelsson
Quoted 4 lines

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.

Quoted 1 line

A number of warnings (see below)

Quoted 7 lines
Quoted 3 lines

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

#10 lore raw
Quoted 6 lines · Richard Purdie
Quoted 3 lines

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

#11 lore raw
Quoted 10 lines · Khem Raj
Quoted 6 lines · Richard Purdie
Quoted 3 lines

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

#12 lore raw
In reply to Richard Purdie
Quoted 10 lines · Richard Purdie
Quoted 8 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

No need to look in the README file with this.

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#13 lore raw

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

Quoted 30 lines · Richard Purdie
Quoted 10 lines
Quoted 8 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

Quoted 1 line

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

#14 lore raw
Quoted 30 lines · Koen Kooi

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

Quoted 28 lines · Richard Purdie
Quoted 9 lines
Quoted 7 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

Quoted 2 lines
Quoted 1 line

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

Quoted 5 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#15 lore raw
In reply to Koen Kooi
Quoted 33 lines · Koen Kooi

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

Quoted 30 lines · Richard Purdie
Quoted 10 lines
Quoted 8 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

Quoted 3 lines
Quoted 1 line

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

Quoted 7 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#16 lore raw

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

Quoted 34 lines · Koen Kooi
Quoted 33 lines

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

Quoted 30 lines · Richard Purdie
Quoted 10 lines
Quoted 8 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

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.

#17 lore raw

2011-12-01 16:37, Koen Kooi skrev:

Quoted 33 lines

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

Quoted 31 lines · Koen Kooi
Quoted 30 lines

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

Quoted 28 lines · Richard Purdie
Quoted 9 lines
Quoted 7 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[format]
subjectprefix = "[meta-angstrom]"

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Quoted 1 line

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

Quoted 6 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#18 lore raw

2011/12/1 Ulf Samuelsson <[email protected]>

Quoted 64 lines

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 = [email protected]

or
meta-angstrom/.git/config
[sendemail]
to = [email protected]
[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.

Quoted 9 lines

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

#19 lore raw
In reply to Ulf Samuelsson

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

Quoted 56 lines

2011-12-01 16:37, Koen Kooi skrev:

Quoted 46 lines

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

Quoted 43 lines · Koen Kooi
Quoted 42 lines

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

Quoted 38 lines · Richard Purdie
Quoted 10 lines
Quoted 10 lines

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.

Quoted 3 lines

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 =
[email protected]

or
meta-angstrom/.git/config
[sendemail]
to =
[email protected]

[format]
subjectprefix = "[meta-angstrom]"

No need to look in the README file with this.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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.

Quoted 6 lines

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?

#20 lore raw
Quoted 62 lines · Koen Kooi

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

Quoted 60 lines

2011-12-01 16:37, Koen Kooi skrev:

Quoted 46 lines

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

Quoted 43 lines · Koen Kooi
Quoted 42 lines

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

Quoted 38 lines · Richard Purdie
Quoted 10 lines
Quoted 10 lines

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.

Quoted 3 lines

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 =
[email protected]

or
meta-angstrom/.git/config
[sendemail]
to =
[email protected]

[format]
subjectprefix = "[meta-angstrom]"

No need to look in the README file with this.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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.

Quoted 4 lines
Quoted 1 line

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

Quoted 5 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#21 lore raw
In reply to Richard Purdie
Quoted 10 lines
Quoted 6 lines

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.

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#22 lore raw
Quoted 6 lines · Ulf Samuelsson
Quoted 6 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 4 lines

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

Quoted 2 lines

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

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
#23 lore raw
Quoted 21 lines · Scott Garman
Quoted 6 lines · Ulf Samuelsson
Quoted 6 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 4 lines

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

Quoted 2 lines

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

Quoted 8 lines

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

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#24 lore raw
Quoted 38 lines · Ulf Samuelsson
Quoted 21 lines · Scott Garman
Quoted 6 lines · Ulf Samuelsson
Quoted 6 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 4 lines

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

Quoted 2 lines

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

Quoted 8 lines

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

Quoted 8 lines

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

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii
#25 lore raw
Quoted 14 lines · Ulf Samuelsson

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

Quoted 6 lines
        after ~2200 out of 2400 tasks.

BR
Ulf

Hi Ulf,

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

Bye Henning

From b96f4d6b73ff993910b635b9dca962fac8eeeb49 Mon Sep 17 00:00:00 2001
From: Henning Heinold <[email protected]>
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(-)
meta/recipes-devtools/gcc/gcc-configure-cross.inc +1 -1
index d2d9081..f42a6ee 100644
@@ -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}"
Signature · 1 line
1.7.7.3
#26 lore raw
Quoted 19 lines · Henning Heinold
Quoted 18 lines · Ulf Samuelsson

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.
Quoted 6 lines
Quoted 2 lines

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

#27 lore raw
Quoted 20 lines · Richard Purdie
Quoted 19 lines · Henning Heinold
Quoted 18 lines · Ulf Samuelsson

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.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines

BR
Ulf

Hi Ulf,

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

Does this really fix the problem.

Quoted 7 lines

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

Quoted 10 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 1 line
-Khem
#28 lore raw
Quoted 21 lines · Khem Raj
Quoted 20 lines · Richard Purdie
Quoted 19 lines · Henning Heinold
Quoted 18 lines · Ulf Samuelsson

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.
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 23 lines
Quoted 6 lines

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

Quoted 9 lines

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Signature · 3 lines
Best Regards
Ulf Samuelsson
eMagii