Re: [yocto] Generating an image with systemd and connman
Hi Christian, On 24.07.2013 05:51, Christian Gagneraud wrote: Hi there, I have successfully generated Dylan core-image-minimal with the meta-ti layer. I would like to know what is the procedure to select systemd for the init process and connman as the network manager. It seems to me that systemd can be selected using EXTRA_IMAGE_FEATURES from local.conf (at least with the poky distro) The Yocto dev manual mention using DISTRO_FEATURES_append but it is usable when creating a custom distro. I have VIRTUAL-RUNTIME_init_manager = systemd VIRTUAL-RUNTIME_initscripts = DISTRO_FEATURES_append = systemd DISTRO_FEATURES_BACKFILL_CONSIDERED=sysvinit in my distro conf file and after that the generated system does only systemd. But I am creating a custom distro so I am not sure if these settings are any help for you. Cheers, Jukka ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FW: FW: [OE-core] Doc: external toolchain
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.commailto:scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In Progress
version of the YP Reference Manual has a new section on toolchains in general.
This section, combined with the TCMODE glossary entry and a FAQ entry, both in
the reference manual, comprise our information on the external toolchain topic.
Let me know what specifically would need additionally addressed and I can get
that on my plate to improve the doc set.
Thanks,
Scott
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#cross-development-toolchain-generation
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-TCMODE
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#idm622640
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.commailto:s...@linux.intel.com]
Sent: Tuesday, July 23, 2013 3:52 PM
To: Rifenbark, Scott M
Subject: Fwd: [OE-core] Doc: external toolchain
Original Message
Subject: [OE-core] Doc: external toolchain
Date: Tue, 23 Jul 2013 23:45:28 +0100
From: Laszlo Papp lp...@kde.orgmailto:lp...@kde.org
To:
openembedded-c...@lists.openembedded.orgmailto:openembedded-c...@lists.openembedded.org
Dear gents and ladies,
it would be nice to get some
Re: [yocto] [PATCH] package_reges.inc: Add/Update REGEX and PRSPV variable
Hi Emilia,
On 18 July 2013 17:09, Emilia Ciobanu
emilia.maria.silvia.ciob...@intel.com wrote:
+PRSPV_pn-unzip = ${@d.getVar('PV',1).replace('.','')}
Looks good.
+PRSPV_pn-docbook-sgml-dtd-3.1-native = 31
+PRSPV_pn-docbook-sgml-dtd-4.1-native = 41
As discussed already, let's rename these files so the PV is in the
filename (i.e. docbook-sgml-dtd-3.1-native_3.1.bb) so these PRSPV
values can do the same as the zip recipes.
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2] package_reges.inc: Add/Update REGEX and PRSPV variable
The PRSPV variable is used for the packages:
* zip
* unzip
* docbook-sgml-dtd-3.1-native
* docbook-sgml-dtd-4.1-native
The REGEX variable has been added/changed for the following packages:
* btrfs-tools
* bjam-native
* build-appliance-image
* mpeg2dec
* mpfr-native
* nativesdk-mpfr
* xf86-video-omap
* remake
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
---
meta-yocto/conf/distro/include/package_regex.inc | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/meta-yocto/conf/distro/include/package_regex.inc
b/meta-yocto/conf/distro/include/package_regex.inc
index 42d17e5..1572729 100644
--- a/meta-yocto/conf/distro/include/package_regex.inc
+++ b/meta-yocto/conf/distro/include/package_regex.inc
@@ -24,11 +24,13 @@ REGEX_URI_pn-beecrypt-native =
http://sourceforge.net/projects/beecrypt/files/b
REGEX_pn-beecrypt-native =
[hH][rR][eE][fF]=\/projects/beecrypt/files/beecrypt/(?Ppver((\d+[\.\-_]*)+))/\
REGEX_pn-bdwgc =
[hH][rR][eE][fF]=\gc\-(?Ppver((\d+[a-z]?[\.\-_]*)+))\.tar\.gz\
REGEX_URI_pn-bjam-native = http://sourceforge.net/projects/boost/files/boost/;
+REGEX_pn-bjam-native =
[hH][rR][eE][fF]=\/projects/boost/files/boost/(?Ppver((\d+[\.\-_]*)+))/\
REGEX_URI_pn-blktool = ftp://ftp.debian.org/debian/pool/main/b/blktool/;
REGEX_pn-blktool =
[hH][rR][eE][fF]=\ftp://ftp.debian.org:21/debian/pool/main/b/blktool/blktool_(?Ppver((\d+[\.\-_]*)+))\.(diff|orig\.tar)\.gz\
REGEX_URI_pn-boost = http://sourceforge.net/projects/boost/files/boost/;
REGEX_pn-boost =
[hH][rR][eE][fF]=\/projects/boost/files/boost/(?Ppver((\d+[\.\-_]*)+))/\
-REGEX_pn-btrfs-tools = (\d+(\.\d+)*(\-rc\d+)*)
+REGEX_pn-btrfs-tools = (?Ppver(\d+(\.\d+)*(\-rc\d+)*))
+REGEX_pn-build-appliance-image = (?Ppver([0-9][\.|_]?)+)$
REGEX_pn-chkconfig-alternatives-native =
chkconfig\-(?Ppver((\d+[\.\-_]*)+))
REGEX_URI_pn-chrpath = http://alioth.debian.org/frs/?group_id=31052;
REGEX_pn-chrpath =
[hH][rR][eE][fF]=\/frs/download.php/file/\d+/chrpath-(?Ppver((\d+[\.\-_]*)+))\.tar\.gz\
@@ -165,13 +167,13 @@ REGEX_pn-minicom =
[hH][rR][eE][fF]=\/frs/download.php/file/\d+/minicom\-(?Pp
REGEX_URI_pn-mingetty =
http://sourceforge.net/projects/mingetty/files/mingetty;
REGEX_pn-mingetty =
[hH][rR][eE][fF]=\/projects/mingetty/files/mingetty/(?Ppver((\d+[\.\-_]*)+))/\
REGEX_URI_pn-mpeg2dec = http://libmpeg2.sourceforge.net/downloads.html;
-REGEX_pn-mpeg2dec =
[hH][rR][eE][fF]=\/files/mpeg2dec-(?Ppver((\d+[\.\-_]*)+)).tar.gz
+REGEX_pn-mpeg2dec =
[hH][rR][eE][fF]=\/files/mpeg2dec-(?Ppver((\d+[\.\-_]*)+)).tar.gz\
REGEX_URI_pn-mpfr = http://ftp.gnu.org/gnu/mpfr/;
REGEX_pn-mpfr = [hH][rR][eE][fF]=\mpfr-(?Ppver((\d+[\.\-_]*)+)).tar.gz
REGEX_URI_pn-mpfr-native = http://ftp.gnu.org/gnu/mpfr/;
-REGEX_pn-mpfr-native =
[hH][rR][eE][fF]=\mpfr-(?Ppver((\d+[\.\-_]*)+)).tar.gz
+REGEX_pn-mpfr-native =
[hH][rR][eE][fF]=\mpfr-(?Ppver((\d+[\.\-_]*)+)).tar.gz\
REGEX_URI_pn-nativesdk-mpfr = http://ftp.gnu.org/gnu/mpfr/;
-REGEX_pn-nativesdk-mpfr =
[hH][rR][eE][fF]=\mpfr-(?Ppver((\d+[\.\-_]*)+)).tar.gz
+REGEX_pn-nativesdk-mpfr =
[hH][rR][eE][fF]=\mpfr-(?Ppver((\d+[\.\-_]*)+)).tar.gz\
REGEX_URI_pn-nfs-utils = http://sourceforge.net/projects/nfs/files/nfs-utils/;
REGEX_pn-nfs-utils =
[hH][rR][eE][fF]=\/projects/nfs/files/nfs-utils/(?Ppver((\d+[\.\-_]*)+))/\
REGEX_URI_pn-ocf-linux =
http://sourceforge.net/projects/ocf-linux/files/ocf-linux/;
@@ -244,8 +246,10 @@ REGEX_URI_pn-tzdata = ftp://ftp.iana.org/tz/releases/;
REGEX_pn-tzdata =
[hH][rR][eE][fF]=\ftp://ftp.iana.org:21/tz/releases/tzdata(?Ppver((\d+[a-z])+))\.tar\.gz\
REGEX_URI_pn-unzip =
http://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/;
REGEX_pn-unzip =
[hH][rR][eE][fF]=\http://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/unzip(?Ppver(\d+))\.tar\.gz/download\
+PRSPV_pn-unzip = ${@d.getVar('PV',1).replace('.','')}
REGEX_URI_pn-unzip-native =
http://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/;
REGEX_pn-unzip-native =
[hH][rR][eE][fF]=\http://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/unzip(?Ppver(\d+))\.tar\.gz/download\
+PRSPV_pn-unzip-native = ${@d.getVar('PV',1).replace('.','')}
REGEX_URI_pn-v86d = http://dev.gentoo.org/~spock/projects/uvesafb/archive/;
REGEX_pn-v86d = [hH][rR][eE][fF]=\v86d\-(?Ppver((\d+[\.]*)+))\.tar\.bz2\
REGEX_URI_pn-watchdog =
http://sourceforge.net/projects/watchdog/files/watchdog/;
@@ -255,16 +259,18 @@ REGEX_pn-wireless-tools =
[hH][rR][eE][fF]=\wireless_tools\.(?Ppver(\d+))\.t
REGEX_URI_pn-x11vnc =
http://sourceforge.net/projects/libvncserver/files/x11vnc/;
REGEX_pn-x11vnc =
[hH][rR][eE][fF]=\/projects/libvncserver/files/x11vnc/(?Ppver((\d+[\.\-_]*)+))/\
REGEX_pn-xdg-utils =
[hH][rR][eE][fF]=\xdg\-utils\-(?Ppver((\d+[\.\-_]*)+))\.(tar\.gz|tgz)\
[yocto] bitbake CaspaVL
Hi all, How do CaspaVL driver can be integrated into Yocto project? Any ideas? -- Regards, Zafrullah Syed ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gcc enable-languages
Dat Tran dtran11@... writes: This is the error I get: configure: WARNING: unrecognized options: --disable-silent-rules, --with- sysroot DEBUG: Shell function do_configure finished DEBUG: Executing python function do_qa_configure NOTE: Checking autotools environment for common misconfiguration ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '/home/appusr/poky/build/tmp/work/armv7a-vfp-neon-poky-linux- gnueabi/libtool-cross-2.4.2-r5.1/libtool-2.4.2' DEBUG: Python function do_qa_configure finished ERROR: Function failed: do_qa_configure Thanks Hello, I followed the same steps to use fortran with Yocto, but get a similar error: ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '/home/mvalle/poky- dylan-9.0.0/build/tmp/work/x86_64-poky-linux/gcc-runtime/4.7.2-r19/gcc- 4.7.2/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky- linux/libgfortran' ERROR: Function failed: do_qa_configure You finally could fix this error? Thanks in advance. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FW: Regarding offline build
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Amit Kumar Sent: Wednesday, July 24, 2013 8:10 AM To: Paul Eggleton Cc: yocto@yoctoproject.org; lee_ball...@dell.com Subject: Re: [yocto] Regarding offline build Hi, I have tried the steps suggested by Mr. Paul. But still i am facing an error to build yocto project offline. First - I use the machine that have full Internet access and execute the - bitbake -c fetchall core-image-minimal Before that i have enabled the DL_DIR in conf/local.conf file. One the fetching done, i remove the internet and build the image - bitbake -k core-image-minimal But still i am facing an error, some packages still required internet access during build. Please find the attached error log with this mail. Please let me know if i missed out any step. Thanks Regards Amit K From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Tuesday, July 23, 2013 4:05 PM To: Amit Kumar Cc: lee_ball...@dell.com; yocto@yoctoproject.org Subject: Re: [yocto] Regarding offline build Amit Kumar wrote: To build the Yocot Project offline, i have done the following- [1] Downloaded the Poky-latest.tar.bz2 [2] Untar it. and enter the poky dir. [3] execute the - source oe-init-build-env [4] edit the conf/local.conf file as per ur suggesion. [5] Build the image - bitbake core-image-minimal But still i am getting an error- To have to look into the error plz find the attached error log- The missing step is you haven't populated DL_DIR (defaults to downloads/ under the build directory) with files that would normally be downloaded by the system, so it is attempting to download them and stopping because BB_NO_NETWORK is set, hence: | ERROR: Function failed: Network access disabled through BB_NO_NETWORK The easiest thing to do is to go to a machine that does have full internet access, untar poky, source oe-init-build-env and then run: bitbake -c fetchall imagename Then copy the contents of DL_DIR to the machine without network access and you should be ready to go. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$ bitbake -c fetchall core-image-minimal Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |##| Time: 00:02:58 Parsing of 813 .bb files complete (0 cached, 813 parsed). 1120 targets, 27 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION= 1.18.0 BUILD_SYS = i686-linux NATIVELSBSTRING = Ubuntu-12.10 TARGET_SYS= i586-poky-linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.4.1 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun and all succeeded. Loading cache: 100% || ETA: 00:00:00 Loaded 1121 entries from dependency cache. Build Configuration: BB_VERSION= 1.18.0 BUILD_SYS = i686-linux NATIVELSBSTRING = Ubuntu-12.10 TARGET_SYS= i586-poky-linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.4.1 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= unknown:unknown NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.7.tar.bz2, attempting MIRRORS if available WARNING: Failed to fetch URL http://www.apache.org/dist/apr/apr-util-1.5.1.tar.gz, attempting MIRRORS if available WARNING: Failed to fetch URL http://www.apache.org/dist/subversion/subversion-1.7.8.tar.bz2, attempting MIRRORS if available NOTE: Tasks Summary: Attempted 282 tasks of which 59 didn't need to be rerun and all succeeded. Summary: There were 3 WARNING messages shown. amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$ vim
[yocto] [PATCH] libcap-ng - new recipe needed for meta-security
A script from the meta-security layer had a missing
dependency that prevented it to work correctly.
Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com
---
meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb | 12
1 file changed, 12 insertions(+)
create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb
diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb
b/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb
new file mode 100644
index 000..a377ddd
--- /dev/null
+++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb
@@ -0,0 +1,12 @@
+DESCRIPTION = The libcap-ng library is intended to make programming with
posix capabilities much easier than the traditional libcap library.
+HOMEPAGE = http://people.redhat.com/sgrubb/libcap-ng/index.html;
+LICENSE = GPL-2.0
+DEPENDS = libcap
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+
+SRC_URI = http://people.redhat.com/sgrubb/libcap-ng/${PN}-${PV}.tar.gz;
+
+SRC_URI[md5sum] = 610afb774f80a8032b711281df126283
+SRC_URI[sha256sum] =
5ca441c8d3a1e4cfe8a8151907977662679457311ccaa7eaac91447c33a35bb1
+
+inherit autotools
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] how to set particular changes to a default kernel config
Dear Yocto Team,
For an ARM based board (MACHINE = myboard), I use a default kernel
config from arch/arm/configs and want now to change some particular
CONFIG_ options.
Trying to follow the documentation, I currently have the following files:
.
+- linux-acme
| |
| +- additional.cfg
|
+- linux-acme_3.8.bb
...in linux-acme_3.8.bb I have
(...)
S = ${WORKDIR}/git
(...)
KERNEL_DEFCONFIG_myboard = blabla_defconfig
do_configure_prepend_myboard() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} \
${WORKDIR}/defconfig || die no default config
}
SRC_URI_myboard = git://kernel.ubuntu.com/ubuntu/linux.git;protocol=git \
file://additional.cfg
(...)
...and in additional.cfg I have
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
When I run something like...
$ bitbake -b /yocto/meta-myboard/recipes-kernel/linux/linux-acme_3.8.bb -f
...it seems to find the .cfg file, since it stoped complaining (after
I fixed some paths) and now compiles/builds smoothely.
Anyway, I can't see the changes in the .config in
$BDIR/tmp/work/myboard-linux-gnueabi/linux-acme/3.8+/git/.config
I imagine something like mixing both configs and running make
oldconfig in behind. Anyway before compilation, the changes should be
in the .config, right?
Questions:
1) How can I add single additional options to a default kernel config?
2) What is the best way to check if the options were applied?
3) Do I need another approach, e.g. through a patch, using echo, or
using a .scc file (I tried, but with the same result)?
Best Regards,
Lothar Rubusch
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to set particular changes to a default kernel config
On 13-07-24 09:05 AM, lot...@denx.de wrote:
Dear Yocto Team,
For an ARM based board (MACHINE = myboard), I use a default kernel
config from arch/arm/configs and want now to change some particular
CONFIG_ options.
Trying to follow the documentation, I currently have the following files:
.
+- linux-acme
| |
| +- additional.cfg
|
+- linux-acme_3.8.bb
...in linux-acme_3.8.bb I have
(...)
S = ${WORKDIR}/git
(...)
KERNEL_DEFCONFIG_myboard = blabla_defconfig
do_configure_prepend_myboard() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} \
${WORKDIR}/defconfig || die no default config
}
SRC_URI_myboard = git://kernel.ubuntu.com/ubuntu/linux.git;protocol=git \
file://additional.cfg
(...)
...and in additional.cfg I have
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
When I run something like...
$ bitbake -b /yocto/meta-myboard/recipes-kernel/linux/linux-acme_3.8.bb -f
...it seems to find the .cfg file, since it stoped complaining (after I
fixed some paths) and now compiles/builds smoothely.
Anyway, I can't see the changes in the .config in
$BDIR/tmp/work/myboard-linux-gnueabi/linux-acme/3.8+/git/.config
I imagine something like mixing both configs and running make
oldconfig in behind. Anyway before compilation, the changes should be
in the .config, right?
Questions:
1) How can I add single additional options to a default kernel config?
Just like you have above, but does your recipe inherit linux-yocto ?
You of course also need to have the dependencies of the options
you are trying to add, otherwise, they won't make the final .config.
2) What is the best way to check if the options were applied?
There's an audit phase that runs after configuration has completed, but
if you are using a different tree than the linux-yocto tree, it will
do it's best to tell you what is missing, but needs to sift through
a lot of data.
A faster way for small changes is likely just what you are doing,
checking the .config in the build dir.
3) Do I need another approach, e.g. through a patch, using echo, or
using a .scc file (I tried, but with the same result)?
Those will work as well, but the system will detect lonely .cfg files
and apply them to the tree after the default configuration.
Cheers,
Bruce
Best Regards,
Lothar Rubusch
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: Regarding offline build
On 2013-07-24 06:48, Amit Kumar wrote: -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Amit Kumar Sent: Wednesday, July 24, 2013 8:10 AM To: Paul Eggleton Cc: yocto@yoctoproject.org; lee_ball...@dell.com Subject: Re: [yocto] Regarding offline build Hi, I have tried the steps suggested by Mr. Paul. But still i am facing an error to build yocto project offline. First - I use the machine that have full Internet access and execute the - bitbake -c fetchall core-image-minimal Before that i have enabled the DL_DIR in conf/local.conf file. One the fetching done, i remove the internet and build the image - bitbake -k core-image-minimal But still i am facing an error, some packages still required internet access during build. Please find the attached error log with this mail. Please let me know if i missed out any step. This process should have worked. What files were in your DL_DIR at the end of the fetchall step? From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Tuesday, July 23, 2013 4:05 PM To: Amit Kumar Cc: lee_ball...@dell.com; yocto@yoctoproject.org Subject: Re: [yocto] Regarding offline build Amit Kumar wrote: To build the Yocot Project offline, i have done the following- [1] Downloaded the Poky-latest.tar.bz2 [2] Untar it. and enter the poky dir. [3] execute the - source oe-init-build-env [4] edit the conf/local.conf file as per ur suggesion. [5] Build the image - bitbake core-image-minimal But still i am getting an error- To have to look into the error plz find the attached error log- The missing step is you haven't populated DL_DIR (defaults to downloads/ under the build directory) with files that would normally be downloaded by the system, so it is attempting to download them and stopping because BB_NO_NETWORK is set, hence: | ERROR: Function failed: Network access disabled through BB_NO_NETWORK The easiest thing to do is to go to a machine that does have full internet access, untar poky, source oe-init-build-env and then run: bitbake -c fetchall imagename Then copy the contents of DL_DIR to the machine without network access and you should be ready to go. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Packaging questions
I'm [still] trying to set up a package for Amanda. I'd like the end result to match how it's done on other systems, e.g. my desktop Fedora box. However, this layout is causing some QA errors which I don't know how to fix, e.g. ERROR: QA Issue: non debug package contains .debug directory: amanda path /work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: amanda path '/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so' I understand the first one but don't know the workaround. How do I tell bitbake that the directory /usr/lib/perl/5.14.2/auto/Amanda/MainLoop contains executable code (and that's OK)? The second issue I think is one of philosophy. The symbolic link is important to the package - how can I set this up to be OK? Thanks for any pointers Note: of course there are many of each of these classes of errors, this is just a representative example. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging questions
On 24 July 2013 14:56, Gary Thomas g...@mlbassoc.com wrote:
I'm [still] trying to set up a package for Amanda. I'd like
the end result to match how it's done on other systems, e.g.
my desktop Fedora box. However, this layout is causing some
QA errors which I don't know how to fix, e.g.
ERROR: QA Issue: non debug package contains .debug directory: amanda path
/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so
This is resolved by fiddling with your FILES lines, the problem being
that PN is packaging that entire tree when it should be split up.
$PN-dbg collects files before $PN so you can add something like
$(libdir)/perl/*/auto/Amanda/*/.debug to FILES_$PN-dbg and $PN will
continue to take the rest.
ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
amanda path
'/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
I'm curious, what does the symlink point to? It's possible that we
can refine the check to reduce the number of false positives, because
this is a fairly common one that needs to be skipped.
You can skip this QA test by setting INSANE_SKIP. In this case,
INSANE_SKIP_${PN} = dev-so (you can identify the tag to use by
looking through classes/insane.bbclass for the error message).
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
It is a different issue I am facing on another computer, so yet another one
to be solved, but here it goes:
ERROR: Multiple .bb files are due to be built which each provide
busybox
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta-foo/recipes-core/busybox/busybox_1.20.2.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/busybox_1.20.2.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/arm-none-linux-gnueabi-libc-for-gcc
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/libc
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/libiconv
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
Any clue? It worked fine in denzil. :(
On Wed, Jul 24, 2013 at 8:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
** **
Can anyone address the toolchain questions here for Laszlo?
** **
Thanks,
Scott
** **
*From:* djsz...@archlinux.us [mailto:djsz...@archlinux.us] *On Behalf Of
*Laszlo
Papp
*Sent:* Tuesday, July 23, 2013 11:52 PM
*To:* Rifenbark, Scott M
*Cc:* Wold, Saul
*Subject:* Re: FW: [OE-core] Doc: external toolchain
** **
OK, thanks.
** **
I am facing this issue, any clue?
** **
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
** **
This is what I have in my build/conf/local.conf:
** **
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
** **
The external toolchain does exist:
** **
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24' --with-bugurl=
https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
Sorry for the noise. Disregard the busybox issue as that has been now
solved. The problem is with the external sourcery toolchain inside the
platform as it seems. At least, the error message has no any reference to
my custom layer.
On Wed, Jul 24, 2013 at 3:14 PM, Laszlo Papp lp...@kde.org wrote:
It is a different issue I am facing on another computer, so yet another
one to be solved, but here it goes:
ERROR: Multiple .bb files are due to be built which each provide busybox
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta-foo/recipes-core/busybox/busybox_1.20.2.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/busybox_1.20.2.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/arm-none-linux-gnueabi-libc-for-gcc
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide virtual/libc
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/libiconv
(/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/eglibc/eglibc_2.17.bb
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
Any clue? It worked fine in denzil. :(
On Wed, Jul 24, 2013 at 8:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
** **
Can anyone address the toolchain questions here for Laszlo?
** **
Thanks,
Scott
** **
*From:* djsz...@archlinux.us [mailto:djsz...@archlinux.us] *On Behalf Of
*Laszlo Papp
*Sent:* Tuesday, July 23, 2013 11:52 PM
*To:* Rifenbark, Scott M
*Cc:* Wold, Saul
*Subject:* Re: FW: [OE-core] Doc: external toolchain
** **
OK, thanks.
** **
I am facing this issue, any clue?
** **
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
** **
This is what I have in my build/conf/local.conf:
** **
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
** **
The external toolchain does exist:
** **
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24' --with-bugurl=
https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
[yocto] Reg: PERL Module
Hi I want to install spamassassin to my image. already I ran bitbake fal-image-full with following line on my conf/local.conf IMAGE_INSTALL_append = perl-modules But still building spamassassing is complaining about PERL modules. NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'libarchive-tar-perl-native' (but /media/sdk/QorIQ-SDK-V1.3-20121114-yocto/meta-fsl-ppc/recipes-test/spamassassin/ spamassassin_3.3.1.bb DEPENDS on or otherwise requires it) ERROR: Required build target 'spamassassin' has no buildable providers. Missing or unbuildable dependency chain was: ['spamassassin', 'libarchive-tar-perl-native'] Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging questions
On 2013-07-24 08:12, Burton, Ross wrote:
On 24 July 2013 14:56, Gary Thomas g...@mlbassoc.com wrote:
I'm [still] trying to set up a package for Amanda. I'd like
the end result to match how it's done on other systems, e.g.
my desktop Fedora box. However, this layout is causing some
QA errors which I don't know how to fix, e.g.
ERROR: QA Issue: non debug package contains .debug directory: amanda path
/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/perl/5.14.2/auto/Amanda/MainLoop/.debug/libMainLoop.so
This is resolved by fiddling with your FILES lines, the problem being
that PN is packaging that entire tree when it should be split up.
$PN-dbg collects files before $PN so you can add something like
$(libdir)/perl/*/auto/Amanda/*/.debug to FILES_$PN-dbg and $PN will
continue to take the rest.
Thanks, this worked a treat.
ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
amanda path
'/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
I'm curious, what does the symlink point to? It's possible that we
can refine the check to reduce the number of false positives, because
this is a fairly common one that needs to be skipped.
The .so symlink points to a fully qualified library, e.g.
-rwxr-xr-x 1 gthomas gthomas 1383729 Jul 24 06:35 libamanda-3.3.3.so
lrwxrwxrwx 1 gthomas gthomas 18 Jul 24 06:35 libamanda.so -
libamanda-3.3.3.so
The problem seems to be that this is the unqualified .so name and not a
version qualified name like 'libamanda.so.3'. The package isn't building
the version qualified names, just the fully unqualified one.
You can skip this QA test by setting INSANE_SKIP. In this case,
INSANE_SKIP_${PN} = dev-so (you can identify the tag to use by
looking through classes/insane.bbclass for the error message).
Ross
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] External toolchain (sourcery)
Hi, is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. Many thanks, Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
I was using that based on the non-official documentation (i.e. presentation
at the Linux event).
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In
Progress version of the YP Reference Manual has a new section on
toolchains
in general. This section, combined with the TCMODE glossary entry and a
FAQ
entry, both in the reference manual, comprise our information on the
external toolchain topic. Let me know what specifically would need
additionally addressed and I can get that on my plate to improve the doc
set.
Thanks,
Scott
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#cross-development-toolchain-generation
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-TCMODE
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#idm622640
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}} %{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In
Progress version of the YP Reference Manual has a new section on toolchains
in general. This section, combined with the TCMODE glossary entry and a FAQ
entry, both in the reference manual, comprise our information on the
external toolchain topic. Let me know what specifically would need
additionally addressed and I can get that on my plate to improve the doc
set.
Thanks,
Scott
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#cross-development-toolchain-generation
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-TCMODE
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#idm622640
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, July 23, 2013 3:52 PM
To: Rifenbark, Scott M
Subject: Fwd: [OE-core] Doc: external toolchain
Original Message
Subject: [OE-core] Doc: external toolchain
Date: Tue, 23 Jul 2013 23:45:28 +0100
From: Laszlo Papp
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
This one to be precise:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /usr/local/arm-2009q1
TARGET_PREFIX = arm-none-linux-gnueabi-
On Wed, Jul 24, 2013 at 4:08 PM, Laszlo Papp lp...@kde.org wrote:
I was using that based on the non-official documentation (i.e.
presentation at the Linux event).
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In
Progress version of the YP Reference Manual has a new section on
toolchains
in general. This section, combined with the TCMODE glossary entry and
a FAQ
entry, both in the reference manual, comprise our information on the
external toolchain topic. Let me know what specifically would need
additionally addressed and I can get that on my plate to improve the doc
set.
Thanks,
Scott
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org wrote:
I was using that based on the non-official documentation (i.e. presentation
at the Linux event).
external-sourcery is the new TCMODE and should work, however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In
Progress version of the YP Reference Manual has a new section on
toolchains
in general. This section, combined with the TCMODE glossary entry and a
FAQ
entry, both in the reference manual, comprise our information on the
external toolchain topic. Let me know what specifically would need
additionally addressed and I can get that on my plate to improve the doc
set.
Thanks,
Scott
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
If I change external-csl to external-sourcery, busybox keeps failing with
the following error:
ERROR: ExpansionError during parsing
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/
busybox_1.20.2.bb: Failure expanding variable do_configure: ExpansionError:
Failure expanding variable do_configure, expression was
do_prepare_config
merge_config.sh -m .config ${@ .join(find_cfgs(d))}
cml1_do_configure
which triggered exception NameError: name 'find_cfgs' is not defined
ERROR: Command execution failed: Exited with 1
Got a clue?
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor btray...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org wrote:
I was using that based on the non-official documentation (i.e.
presentation
at the Linux event).
external-sourcery is the new TCMODE and should work, however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com
wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Re: [yocto] how to set particular changes to a default kernel config
Hi, thank you very much for your answer!
So, you mean something like this in the kernel .bb:
require recipes-kernel/linux/linux-yocto.inc
This is definitely missing. I'm including linux.inc changing it to
linux-yocto.inc breaks other patches that I'd like to apply (perhaps
the path?). This means more work, and more doubts, too.
Now I'm asking myself, actually, should I change it from linux.inc to
linux-yocto.inc generally?
At the moment, I'll apply the CONFIG_'s with echo, which seems
easier for the simple case.
BR,
L
Zitat von Bruce Ashfield bruce.ashfi...@windriver.com:
On 13-07-24 09:05 AM, lot...@denx.de wrote:
Dear Yocto Team,
For an ARM based board (MACHINE = myboard), I use a default kernel
config from arch/arm/configs and want now to change some particular
CONFIG_ options.
Trying to follow the documentation, I currently have the following files:
.
+- linux-acme
| |
| +- additional.cfg
|
+- linux-acme_3.8.bb
...in linux-acme_3.8.bb I have
(...)
S = ${WORKDIR}/git
(...)
KERNEL_DEFCONFIG_myboard = blabla_defconfig
do_configure_prepend_myboard() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} \
${WORKDIR}/defconfig || die no default config
}
SRC_URI_myboard = git://kernel.ubuntu.com/ubuntu/linux.git;protocol=git \
file://additional.cfg
(...)
...and in additional.cfg I have
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
When I run something like...
$ bitbake -b /yocto/meta-myboard/recipes-kernel/linux/linux-acme_3.8.bb -f
...it seems to find the .cfg file, since it stoped complaining (after I
fixed some paths) and now compiles/builds smoothely.
Anyway, I can't see the changes in the .config in
$BDIR/tmp/work/myboard-linux-gnueabi/linux-acme/3.8+/git/.config
I imagine something like mixing both configs and running make
oldconfig in behind. Anyway before compilation, the changes should be
in the .config, right?
Questions:
1) How can I add single additional options to a default kernel config?
Just like you have above, but does your recipe inherit linux-yocto ?
You of course also need to have the dependencies of the options
you are trying to add, otherwise, they won't make the final .config.
2) What is the best way to check if the options were applied?
There's an audit phase that runs after configuration has completed, but
if you are using a different tree than the linux-yocto tree, it will
do it's best to tell you what is missing, but needs to sift through
a lot of data.
A faster way for small changes is likely just what you are doing,
checking the .config in the build dir.
3) Do I need another approach, e.g. through a patch, using echo, or
using a .scc file (I tried, but with the same result)?
Those will work as well, but the system will detect lonely .cfg files
and apply them to the tree after the default configuration.
Cheers,
Bruce
Best Regards,
Lothar Rubusch
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Discovering available Perl modules OR writing recipes for your own
Hi all, I'm working on a recipe for pullledpork, which is a Perl app which grabs and combines Snort rules from various sites. My questions all revolve around pulledpork's various module dependencies. pulledpork tries to use the module Crypt::SSLeay and in my current configuration it can't find it. It is very easy to write a little recipes that provides this module and forge ahead. But I'm not sure that that is the correct thing to do...especially as it looks like I'll have to do the same thing for another ten or so tiny modules if I take that approach. First, is there some way that I can find out whether that or any particular Perl module is provided by some recipe somewhere? My plan would be to RDEPEND on every available Perl module, forcing them all to be installed in the right place, run the pulledpork script, do the right think to provide any modules still missing until the script can actually complete, and then remove from RDEPENDS all previously included modules that don't show up a values in %INC. So far, so good, but I don't know how to even locate all the Perl modules that are already available. Second, if the modules really are not available is there a better way to package them up than writing individual recipes for each and every missing module? Third, are there naming conventions that should be followed? For example there is a recipe for liburi-perl that provides the very simply named Perl module URI. Thanks! - mulhern ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to set particular changes to a default kernel config
On 13-07-24 11:23 AM, lot...@denx.de wrote:
Hi, thank you very much for your answer!
So, you mean something like this in the kernel .bb:
require recipes-kernel/linux/linux-yocto.inc
This is definitely missing. I'm including linux.inc changing it to
linux-yocto.inc breaks other patches that I'd like to apply (perhaps the
path?). This means more work, and more doubts, too.
Now I'm asking myself, actually, should I change it from linux.inc to
linux-yocto.inc generally?
Look a linux-yocto-custom (in meta-skelton), using linux-yocto
kernel bbclass support means that you have fragments, but don't
need to use the linux-yocto kernel tree.
At the moment, I'll apply the CONFIG_'s with echo, which seems easier
for the simple case.
Linux yocto custom is simple, and intended for your use case .. give
it a whirl!
Bruce
BR,
L
Zitat von Bruce Ashfield bruce.ashfi...@windriver.com:
On 13-07-24 09:05 AM, lot...@denx.de wrote:
Dear Yocto Team,
For an ARM based board (MACHINE = myboard), I use a default kernel
config from arch/arm/configs and want now to change some particular
CONFIG_ options.
Trying to follow the documentation, I currently have the following
files:
.
+- linux-acme
| |
| +- additional.cfg
|
+- linux-acme_3.8.bb
...in linux-acme_3.8.bb I have
(...)
S = ${WORKDIR}/git
(...)
KERNEL_DEFCONFIG_myboard = blabla_defconfig
do_configure_prepend_myboard() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} \
${WORKDIR}/defconfig || die no default config
}
SRC_URI_myboard =
git://kernel.ubuntu.com/ubuntu/linux.git;protocol=git \
file://additional.cfg
(...)
...and in additional.cfg I have
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
When I run something like...
$ bitbake -b
/yocto/meta-myboard/recipes-kernel/linux/linux-acme_3.8.bb -f
...it seems to find the .cfg file, since it stoped complaining (after I
fixed some paths) and now compiles/builds smoothely.
Anyway, I can't see the changes in the .config in
$BDIR/tmp/work/myboard-linux-gnueabi/linux-acme/3.8+/git/.config
I imagine something like mixing both configs and running make
oldconfig in behind. Anyway before compilation, the changes should be
in the .config, right?
Questions:
1) How can I add single additional options to a default kernel config?
Just like you have above, but does your recipe inherit linux-yocto ?
You of course also need to have the dependencies of the options
you are trying to add, otherwise, they won't make the final .config.
2) What is the best way to check if the options were applied?
There's an audit phase that runs after configuration has completed, but
if you are using a different tree than the linux-yocto tree, it will
do it's best to tell you what is missing, but needs to sift through
a lot of data.
A faster way for small changes is likely just what you are doing,
checking the .config in the build dir.
3) Do I need another approach, e.g. through a patch, using echo, or
using a .scc file (I tried, but with the same result)?
Those will work as well, but the system will detect lonely .cfg files
and apply them to the tree after the default configuration.
Cheers,
Bruce
Best Regards,
Lothar Rubusch
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: Regarding offline build
Hi, I have tried the steps suggested by Mr. Paul. But still i am facing an error to build yocto project offline. First - I use the machine that have full Internet access and execute the - bitbake -c fetchall core-image-minimal Before that i have enabled the DL_DIR in conf/local.conf file. One the fetching done, i remove the internet and build the image - bitbake -k core-image-minimal But still i am facing an error, some packages still required internet access during build. Please find the attached error log with this mail. Please let me know if i missed out any step. This process should have worked. What files were in your DL_DIR at the end of the fetchall step? After the end of fetchall step.. the files avaliable under the download is - amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$ cd downloads/ backport/debian/ eglibc-2.17/ etc/ git2/licenses/ share/ amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build$ /// Check again after the build error - amit@amit-HP:~/Downloads/poky-dylan-9.0.1/build/downloads$ ls 0001-crtstuff.c-USE_PT_GNU_EH_FRAME-Define-for-systems-us.patch.done host.conf.done 0001-eglibc-menuconfig-support.patch.done hostname.sh.done 0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch.donehosts.done 0001-Fixing-keyboard_force_release.sh-shell-script-path.patch.done hwclock.sh.done 0001-libffi-update-for-3.0.11.patch.done improve_auto_header_gen.patch.done 0001-Makefile.in-vis_hide-gen-hide-list-Do-not-make-defin.patch.done inetd.conf.done 0001-man-disable-man-page-generation-because-we-don-t-hav.patch.done inetd.done 0001-R_ARM_TLS_DTPOFF32.patch.doneinit.done 0002-eglibc-menuconfig-hex-string-options.patch.done initgroups_keys.patch.done 0003-eglibc-menuconfig-build-instructions.patch.done inittab.done 04-default-is-optimized.patch.done input.patch.done 05-enable-ctypes-cross-build.patch.done inputrc.done 06-ctypes-libffi-fix-configure.patch.done install.patch.done 100-uclibc-conf.patch.done interfaces.done 10-distutils-fix-swig-parameter.patch.done int-is-not-the-same-size-as-size_t.patch.done 11-distutils-never-modify-shebang-line.patch.done IO-acquire-lock-fix.patch.done 12-distutils-prefix-is-inside-staging-area.patch.done issue.done 187b7b1646ee.patch.done issue.net.done 200-uclibc-locale.patch.done kconfig-frontends-3.8.0.0.tar.xz 203-uclibc-locale-no__x.patch.done kconfig-frontends-3.8.0.0.tar.xz.done 204-uclibc-locale-wchar_fix.patch.done ldflags.patch.done 205-uclibc-locale-update.patch.done lib-build-fix.patch.done 301-missing-execinfo_h.patch.done libcap2_2.22.orig.tar.gz 302-c99-snprintf.patch.done libcap2_2.22.orig.tar.gz.done 303-c99-complex-ugly-hack.patch.done libffi-3.0.11.tar.gz 304-index_macro.patch.done libffi-3.0.11.tar.gz.done 305-libmudflap-susv3-legacy.patch.done libgcc-sjlj-check.patch.done 306-libstdc++-namespace.patch.done libgcrypt-1.5.0.tar.gz 64bithack.patch.done libgcrypt-1.5.0.tar.gz.done 740-sh-pr24836.patch.done libgpg-error-1.11.tar.bz2 800-arm-bigendian.patch.done libgpg-error-1.11.tar.bz2.done aarch64-adding-build-support.patch.done libiberty_path_fix.patch.done ac_config_links.patch.done libmpc_fix_for_automake-1.12.patch.done acinclude.m4.done libtasn1-2.14.tar.gz acl-2.2.51.src.tar.gz libtasn1-2.14.tar.gz.done acl-2.2.51.src.tar.gz.done libtasn1_fix_for_automake_1.12.patch.done aclocal.tgz.done libtool-2.4.2.tar.gz add-aarch64-support.patch.done libtool-2.4.2.tar.gz.done add-md5module-support.patch.done libtool-2.4-update.patch.done
Re: [yocto] [PATCH] libcap-ng - new recipe needed for meta-security
Hi Andrei, On Wednesday 24 July 2013 15:55:37 Andrei Dinu wrote: A script from the meta-security layer had a missing dependency that prevented it to work correctly. Signed-off-by: Andrei Dinu andrei.adrianx.d...@intel.com --- meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb | 12 1 file changed, 12 insertions(+) create mode 100644 meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb diff --git a/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb b/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb new file mode 100644 index 000..a377ddd --- /dev/null +++ b/meta/recipes-support/libcap-ng/libcap-ng_0.7.3.bb @@ -0,0 +1,12 @@ +DESCRIPTION = The libcap-ng library is intended to make programming with posix capabilities much easier than the traditional libcap library. +HOMEPAGE = http://people.redhat.com/sgrubb/libcap-ng/index.html; +LICENSE = GPL-2.0 +DEPENDS = libcap Does libcap-ng really need libcap or is it effectively a replacement for it? I don't see a check in the configure script for it and the Fedora spec file doesn't mention it either. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
Here you can find the two outputs for bitbake -e busybox. The broken
sourcery, and not so broken csl:
http://ix.io/6QZ
http://ix.io/6R1
Yeah, I know it is a bad practice to paste files to a mailing list, so
forgive that for me now, please.
On Wed, Jul 24, 2013 at 4:20 PM, Laszlo Papp lp...@kde.org wrote:
If I change external-csl to external-sourcery, busybox keeps failing with
the following error:
ERROR: ExpansionError during parsing
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/
busybox_1.20.2.bb: Failure expanding variable do_configure:
ExpansionError: Failure expanding variable do_configure, expression was
do_prepare_config
merge_config.sh -m .config ${@ .join(find_cfgs(d))}
cml1_do_configure
which triggered exception NameError: name 'find_cfgs' is not defined
ERROR: Command execution failed: Exited with 1
Got a clue?
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor btray...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org wrote:
I was using that based on the non-official documentation (i.e.
presentation
at the Linux event).
external-sourcery is the new TCMODE and should work, however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com
wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf
Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/--disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
Re: [yocto] Hob found an error
Hi all, I am getting exactly same error while trying to build a image using hob. I am also trying to add some additional packages and gst plugins. was this issue resolved ? how can i get rid of this error ? I am using imx6q board and and image is fsl-image-gui. regards, venkatesh ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
It seems I can reproduce the issue with even beagleboard + poky using poky
dylan vanilla.
Anyone mind fixing this very nasty bug?
On Wed, Jul 24, 2013 at 5:46 PM, Laszlo Papp lp...@kde.org wrote:
Here you can find the two outputs for bitbake -e busybox. The broken
sourcery, and not so broken csl:
http://ix.io/6QZ
http://ix.io/6R1
Yeah, I know it is a bad practice to paste files to a mailing list, so
forgive that for me now, please.
On Wed, Jul 24, 2013 at 4:20 PM, Laszlo Papp lp...@kde.org wrote:
If I change external-csl to external-sourcery, busybox keeps failing with
the following error:
ERROR: ExpansionError during parsing
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/
busybox_1.20.2.bb: Failure expanding variable do_configure:
ExpansionError: Failure expanding variable do_configure, expression was
do_prepare_config
merge_config.sh -m .config ${@ .join(find_cfgs(d))}
cml1_do_configure
which triggered exception NameError: name 'find_cfgs' is not defined
ERROR: Command execution failed: Exited with 1
Got a clue?
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor btray...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org wrote:
I was using that based on the non-official documentation (i.e.
presentation
at the Linux event).
external-sourcery is the new TCMODE and should work, however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor btray...@gmail.com
wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us [mailto:djsz...@archlinux.us] On Behalf
Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads
--disable-libmudflap
--disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/--disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
On 07/24/2013 11:11 AM, Laszlo Papp wrote:
It seems I can reproduce the issue with even beagleboard + poky using
poky dylan vanilla.
Anyone mind fixing this very nasty bug?
Please file a bug and include your local.conf and any other
configuration files and setup information you have. I will look at it
and assign it to the correct person.
Sau!
On Wed, Jul 24, 2013 at 5:46 PM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
Here you can find the two outputs for bitbake -e busybox. The
broken sourcery, and not so broken csl:
http://ix.io/6QZ
http://ix.io/6R1
Yeah, I know it is a bad practice to paste files to a mailing list,
so forgive that for me now, please.
On Wed, Jul 24, 2013 at 4:20 PM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
If I change external-csl to external-sourcery, busybox keeps
failing with the following error:
ERROR: ExpansionError during parsing
/home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.0/meta/recipes-core/busybox/busybox_1.20.2.bb
http://busybox_1.20.2.bb: Failure expanding variable
do_configure: ExpansionError: Failure expanding variable
do_configure, expression was do_prepare_config
merge_config.sh -m .config ${@ .join(find_cfgs(d))}
cml1_do_configure
which triggered exception NameError: name 'find_cfgs' is not
defined
ERROR: Command execution failed: Exited with 1
Got a clue?
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor
btray...@gmail.com mailto:btray...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
I was using that based on the non-official documentation
(i.e. presentation
at the Linux event).
external-sourcery is the new TCMODE and should work,
however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor
btray...@gmail.com mailto:btray...@gmail.com wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com
mailto:scott.m.rifenb...@intel.com wrote:
Hi,
Can anyone address the toolchain questions here for
Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us
mailto:djsz...@archlinux.us [mailto:djsz...@archlinux.us
mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain
version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command
not found
ERROR: Failed to obtain CodeSourcery toolchain
version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command
not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
Yeah, I already filed a bugreport:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899
On Wed, Jul 24, 2013 at 7:16 PM, Saul Wold saul.w...@intel.com wrote:
On 07/24/2013 11:11 AM, Laszlo Papp wrote:
It seems I can reproduce the issue with even beagleboard + poky using
poky dylan vanilla.
Anyone mind fixing this very nasty bug?
Please file a bug and include your local.conf and any other
configuration files and setup information you have. I will look at it and
assign it to the correct person.
Sau!
On Wed, Jul 24, 2013 at 5:46 PM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
Here you can find the two outputs for bitbake -e busybox. The
broken sourcery, and not so broken csl:
http://ix.io/6QZ
http://ix.io/6R1
Yeah, I know it is a bad practice to paste files to a mailing list,
so forgive that for me now, please.
On Wed, Jul 24, 2013 at 4:20 PM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
If I change external-csl to external-sourcery, busybox keeps
failing with the following error:
ERROR: ExpansionError during parsing
/home/lpapp/Projects/foo/**Yocto/poky-dylan-9.0.0/meta/**
recipes-core/busybox/busybox_**1.20.2.bb http://busybox_1.20.2.bb
http://busybox_1.20.2.bb: Failure expanding variable
do_configure: ExpansionError: Failure expanding variable
do_configure, expression was do_prepare_config
merge_config.sh -m .config ${@ .join(find_cfgs(d))}
cml1_do_configure
which triggered exception NameError: name 'find_cfgs' is not
defined
ERROR: Command execution failed: Exited with 1
Got a clue?
On Wed, Jul 24, 2013 at 4:12 PM, Bill Traynor
btray...@gmail.com mailto:btray...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:08 AM, Laszlo Papp lp...@kde.org
mailto:lp...@kde.org wrote:
I was using that based on the non-official documentation
(i.e. presentation
at the Linux event).
external-sourcery is the new TCMODE and should work,
however, I just
thought trying the old one may work.
On Wed, Jul 24, 2013 at 4:06 PM, Bill Traynor
btray...@gmail.com mailto:btray...@gmail.com wrote:
Try with:
TCMODE = external-csl
EXTERNAL_TOOLCHAIN = /path/to/sourcery/toolchain
On Wed, Jul 24, 2013 at 3:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com
mailto:scott.m.rifenbark@**intel.comscott.m.rifenb...@intel.com
wrote:
Hi,
Can anyone address the toolchain questions here for
Laszlo?
Thanks,
Scott
From: djsz...@archlinux.us
mailto:djsz...@archlinux.us [mailto:djsz...@archlinux.us
mailto:djsz...@archlinux.us] On Behalf Of
Laszlo
Papp
Sent: Tuesday, July 23, 2013 11:52 PM
To: Rifenbark, Scott M
Cc: Wold, Saul
Subject: Re: FW: [OE-core] Doc: external toolchain
OK, thanks.
I am facing this issue, any clue?
ERROR: Failed to obtain CodeSourcery toolchain
version: Execution of
'/usr/bin/i686-pc-linux-gnu-**gcc -v' failed: command
not found
ERROR: Failed to obtain CodeSourcery toolchain
version: Execution of
'/usr/bin/i686-pc-linux-gnu-**gcc -v' failed: command
not found
This is what I have in my build/conf/local.conf:
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
The external toolchain does exist:
/usr/bin/arm-none-linux-**gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-**linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/.**./libexec/gcc/arm-none-linux-
Re: [yocto] FW: FW: [OE-core] Doc: external toolchain
This issue is fixed by not having the default MACHINE ??= qemux86, but a
real arm machine, like beagleboard.
On Wed, Jul 24, 2013 at 8:47 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Hi,
** **
Can anyone address the toolchain questions here for Laszlo?
** **
Thanks,
Scott
** **
*From:* djsz...@archlinux.us [mailto:djsz...@archlinux.us] *On Behalf Of
*Laszlo
Papp
*Sent:* Tuesday, July 23, 2013 11:52 PM
*To:* Rifenbark, Scott M
*Cc:* Wold, Saul
*Subject:* Re: FW: [OE-core] Doc: external toolchain
** **
OK, thanks.
** **
I am facing this issue, any clue?
** **
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
ERROR: Failed to obtain CodeSourcery toolchain version: Execution of
'/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found
** **
This is what I have in my build/conf/local.conf:
** **
...
TCMODE = external-sourcery
EXTERNAL_TOOLCHAIN = /usr
TARGET_PREFIX = arm-none-linux-gnueabi-
...
** **
The external toolchain does exist:
** **
/usr/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/scratch/jbrown/2013.05-arm-linux-release/src/gcc-4.7-2013.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-extra-sgxxlite-multilibs
--with-arch=armv5te --with-gnu-as --with-gnu-ld --with-specs='%{save-temps:
-fverbose-asm}
%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
-D__CS_SOURCERYGXX_MAJ__=2013 -D__CS_SOURCERYGXX_MIN__=5
-D__CS_SOURCERYGXX_REV__=24 %{O2:%{!fno-remove-local-statics:
-fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics:
-fremove-local-statics}}}' --enable-languages=c,c++ --enable-shared
--enable-lto --enable-symvers=gnu --enable-__cxa_atexit
--with-pkgversion='Sourcery CodeBench Lite 2013.05-24' --with-bugurl=
https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-ppl=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-libelf=/scratch/jbrown/2013.05-arm-linux-release/obj/pkg-2013.05-24-arm-none-linux-gnueabi/arm-2013.05-24-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --enable-poison-system-directories
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/jbrown/2013.05-arm-linux-release/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24)
** **
On Wed, Jul 24, 2013 at 7:19 AM, Rifenbark, Scott M
scott.m.rifenb...@intel.com wrote:
Laszlo,
Saul forwarded me this email regarding external toolchains. The In
Progress version of the YP Reference Manual has a new section on
toolchains in general. This section, combined with the TCMODE glossary
entry and a FAQ entry, both in the reference manual, comprise our
information on the external toolchain topic. Let me know what specifically
would need additionally addressed and I can get that on my plate to improve
the doc set.
Thanks,
Scott
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#cross-development-toolchain-generation
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-TCMODE
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#idm622640
-Original Message-
From: Saul Wold [mailto:s...@linux.intel.com]
Sent: Tuesday, July 23, 2013 3:52 PM
Re: [yocto] External toolchain (sourcery)
On 25/07/13 02:49, Laszlo Papp wrote: Hi, is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. FYI, The arago project uses an external Linaro toolchain [1] Chris [1] http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment Many thanks, Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: Hi, is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. Many thanks, Laszlo Check out the documentation but bitbake meta-toolchain or one of the similar flavors should give you what you are looking for. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
1) Is that really from sourcery? 2) What documentation? 3) BTW, the question was whether sourcery is officially supported. On Wed, Jul 24, 2013 at 9:55 PM, Brian Hutchinson b.hutch...@gmail.comwrote: On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: Hi, is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. Many thanks, Laszlo Check out the documentation but bitbake meta-toolchain or one of the similar flavors should give you what you are looking for. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson b.hutch...@gmail.comwrote: On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. I'm not certain as to the official Yocto support stance on external-sourcery as it exists in or-core at this time, but if you do want to use the Sourcery G++ toolchain rather than one of the alternatives suggested by others in this thread, you can use the meta-sourcery layer, which while it isn't officially supported by Yocto, is officially supported by Mentor Graphics, the company which provides the aforementioned toolchain. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
On Wed, Jul 24, 2013 at 4:59 PM, Laszlo Papp lp...@kde.org wrote: 1) Is that really from sourcery? 2) What documentation? 3) BTW, the question was whether sourcery is officially supported. Yocto's default action is to build the toolchain from source and no it isn't Code Sourcery if that is what you are wanting to know. You can configure Yocto to not build the toolchain and use one you provide but I've never tried it. https://www.yoctoproject.org/documentation/current should give you light bedtime reading material. Angstrom Arago as mentioned before use Linaro which has all the latest ARM patches. Regards, Brian ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
I believe the developer story would be simpler with oe-core as opposed to meta-sourcery. Besides, some documentation would be nice to have how to use it, how it will work alongside the oe-core example, and so forth. You know, something similar to what the Linaro people seem to have. On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson b.hutch...@gmail.comwrote: On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. I'm not certain as to the official Yocto support stance on external-sourcery as it exists in or-core at this time, but if you do want to use the Sourcery G++ toolchain rather than one of the alternatives suggested by others in this thread, you can use the meta-sourcery layer, which while it isn't officially supported by Yocto, is officially supported by Mentor Graphics, the company which provides the aforementioned toolchain. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
Also, it seems to be a bit less lightweight than what we have in oe-core. I would not like to pull unnecessary recipes in. Is it possible to work the oe-core stuff around? On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp lp...@kde.org wrote: I believe the developer story would be simpler with oe-core as opposed to meta-sourcery. Besides, some documentation would be nice to have how to use it, how it will work alongside the oe-core example, and so forth. You know, something similar to what the Linaro people seem to have. On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson b.hutch...@gmail.comwrote: On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. I'm not certain as to the official Yocto support stance on external-sourcery as it exists in or-core at this time, but if you do want to use the Sourcery G++ toolchain rather than one of the alternatives suggested by others in this thread, you can use the meta-sourcery layer, which while it isn't officially supported by Yocto, is officially supported by Mentor Graphics, the company which provides the aforementioned toolchain. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Weekly build is now available.
The weekly build is now available. Please being weekly testing as soon as possible. Known issues: - nightly-arm appears to have a hung bitbake process due to a timed out sanity test. - nightly-qa-systemd sanity tests failed to start qemu -b http://autobuilder.yoctoproject.org/pub/nightly/20130724-2 eclipse-poky76df60597ae7cce069a5f1fd45089ea04c7394cd meta-fsl-arm4b8f1b4f11f21043d4a37b1c294fafb8f37f8498 meta-fsl-ppc5d98580e7b366ef25e917b3c446308de28c8cbd4 meta-intel bd34513dc12c412f40328001c09fa5407041e912 meta-minnow a1cfe0e7fc59eb1e430db07840d6b6d54b8733e2 meta-qt3b73552fb998fd30a01dbee5a172e432a16078222 poky67864ca79da08df752487a3a4e1a975546da123d -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Generating an image with systemd and connman
On 24/07/13 19:31, Jukka Rissanen wrote: Hi Christian, On 24.07.2013 05:51, Christian Gagneraud wrote: Hi there, I have successfully generated Dylan core-image-minimal with the meta-ti layer. I would like to know what is the procedure to select systemd for the init process and connman as the network manager. It seems to me that systemd can be selected using EXTRA_IMAGE_FEATURES from local.conf (at least with the poky distro) The Yocto dev manual mention using DISTRO_FEATURES_append but it is usable when creating a custom distro. I have VIRTUAL-RUNTIME_init_manager = systemd VIRTUAL-RUNTIME_initscripts = DISTRO_FEATURES_append = systemd DISTRO_FEATURES_BACKFILL_CONSIDERED=sysvinit in my distro conf file and after that the generated system does only systemd. But I am creating a custom distro so I am not sure if these settings are any help for you. Thanks, I might have to go this way at some point anyway. Are you using the meta-systemd layer? If so, could you give me more details about your setup please? Chris Cheers, Jukka ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Configuring Channels for Smart PM
Hi, I'm looking to use a bbappend to add a repository/channel that the smart package manager can use out of the box. For zypper, this was just a question of adding a configuration file to the recipe. How might I preconfigure Smart? The only way I've come up with so far is a postinst 'smart channel --add' Thanks, --Ash ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
So, is there any workaround in any way to get unblocked or I should just switch away from Yocto for now? Unfortunately, if no workaround comes, I do not have any other option because then it just does not work. :( https://bugzilla.yoctoproject.org/show_bug.cgi?id=4899 Note, I have no clue how to use the meta-sourcery layer, and it has no any proper documentation about that, nor example, like the Linaro guys nicely made one for their solution. On Wed, Jul 24, 2013 at 10:32 PM, Laszlo Papp lp...@kde.org wrote: Also, it seems to be a bit less lightweight than what we have in oe-core. I would not like to pull unnecessary recipes in. Is it possible to work the oe-core stuff around? On Wed, Jul 24, 2013 at 10:23 PM, Laszlo Papp lp...@kde.org wrote: I believe the developer story would be simpler with oe-core as opposed to meta-sourcery. Besides, some documentation would be nice to have how to use it, how it will work alongside the oe-core example, and so forth. You know, something similar to what the Linaro people seem to have. On Wed, Jul 24, 2013 at 9:59 PM, Chris Larson clar...@kergoth.comwrote: On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson b.hutch...@gmail.comwrote: On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp lp...@kde.org wrote: is this officially supported by the Yocto project? I would not like to use Yocto for my own purposes if it is something unsupported, and I would need to put a significant investment into to it to make the releases buildable, et cetera. I'm not certain as to the official Yocto support stance on external-sourcery as it exists in or-core at this time, but if you do want to use the Sourcery G++ toolchain rather than one of the alternatives suggested by others in this thread, you can use the meta-sourcery layer, which while it isn't officially supported by Yocto, is officially supported by Mentor Graphics, the company which provides the aforementioned toolchain. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Doc: external toolchain
On Jul 24, 2013, at 12:47 AM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I am facing this issue, any clue? ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found This is what I have in my build/conf/local.conf: ... TCMODE = external-sourcery EXTERNAL_TOOLCHAIN = /usr TARGET_PREFIX = arm-none-linux-gnueabi- ... what machine are you building for? it seems you are building for a x86 target and expect arm cross toolchain to build it aint gonna work. chose a proper arm'ish machine and it should work.___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Doc: external toolchain
You seem to have missed this email: https://lists.yoctoproject.org/pipermail/yocto/2013-July/017416.html On Thu, Jul 25, 2013 at 6:47 AM, Khem Raj raj.k...@gmail.com wrote: On Jul 24, 2013, at 12:47 AM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: I am facing this issue, any clue? ** ** ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found ERROR: Failed to obtain CodeSourcery toolchain version: Execution of '/usr/bin/i686-pc-linux-gnu-gcc -v' failed: command not found ** ** This is what I have in my build/conf/local.conf: ** ** ... TCMODE = external-sourcery EXTERNAL_TOOLCHAIN = /usr TARGET_PREFIX = arm-none-linux-gnueabi- ... what machine are you building for? it seems you are building for a x86 target and expect arm cross toolchain to build it aint gonna work. chose a proper arm'ish machine and it should work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
