Feedback on building openembedded-core for qemuarm. Excerpts from buildlog
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
@@ -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
@@ -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
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
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_THREADSsetting ?
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
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_THREADSsetting ?
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
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_THREADSsetting ?
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
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_THREADSsetting ?
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 withBB_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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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?
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
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
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
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
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
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_TASKSBB_NUMBER_TASKSBUILD 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
@@ -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
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_TASKSBB_NUMBER_TASKSBUILD TIME
2 2
1:24:16
4 4
0:48:22
6 6
0:45:00
24 24
C++ compiler fails with --sysroot problemafter ~2200 out of 2400 tasks.
Quoted 6 lines
Quoted 2 lines
BR
UlfHi 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
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_TASKSBB_NUMBER_TASKSBUILD TIME
2 2
1:24:16
4 4
0:48:22
6 6
0:45:00
24 24
C++ compiler fails with --sysroot problemafter ~2200 out of 2400 tasks.
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
BR
UlfHi 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
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_TASKSBB_NUMBER_TASKSBUILD TIME
2 2
1:24:16
4 4
0:48:22
6 6
0:45:00
24 24
C++ compiler fails with --sysroot problemafter ~2200 out of 2400 tasks.
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
BR
UlfHi 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