Re: [yocto] Trying to compile mono on target for machine crownbay
On Wed, Feb 20, 2013 at 11:30 AM, Evgheni Antropov aid...@gmail.com wrote: In my case I have resolved it in another way: correct in Makefile for eglib folder SUBDIRS variables and excluded test from them values: - egrep SUBDIRS = ./mono-2.10.2/build/eglib/Makefile DIST_SUBDIRS = src test SUBDIRS = src test #SUBDIRS = src #SUBDIRS = src #SUBDIRS = src + egrep SUBDIRS = ./mono-2.10.2/build/eglib/Makefile DIST_SUBDIRS = src SUBDIRS = src #SUBDIRS = src #SUBDIRS = src #SUBDIRS = src build is my own directory where I'm compiling mono. Just FYI - meta-mono is available as a layer that can build mono on a build machine (cross compilation) instead of natively compiling mono in target device. http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mono][PATCH 2/2] monotools-server: Remove multiline comment
On Mon, Jan 21, 2013 at 6:17 PM, Khem Raj raj.k...@gmail.com wrote:
bitbake/master does not like it anymore
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../monotools-server/monotools-server_2.0.bb |2 --
1 file changed, 2 deletions(-)
diff --git a/recipes-mono/monotools-server/monotools-server_2.0.bb
b/recipes-mono/monotools-server/monotools-server_2.0.bb
index 551c586..ef738da 100644
--- a/recipes-mono/monotools-server/monotools-server_2.0.bb
+++ b/recipes-mono/monotools-server/monotools-server_2.0.bb
@@ -22,8 +22,6 @@ SRC_URI += \
file://fix-pkglib_SCRIPTS.patch \
-# file://Makefile-pkglib.patch \
-
DEPENDS = mono-xsp gtk-sharp
S = ${WORKDIR}/${PN}
--
1.7.9.5
Merged into master
Apologies for late merge - somehow this got lost because of bad email
filtering on my part.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Busybox still old version: Still looking for a clear understanding of an old mystery.
On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker b...@bsmucker.eu.org wrote: Hi Rudolf, On 1/15/2013 3:28 PM, Rudolf Streif wrote: Brian, What are you exactly referring to as new version? The package version that bitbake builds is defined by the recipe, through the version designation in the recipe's file name or through explicitly setting PV. I think what you are trying to do is to modify the busybox configuration and then recompile and package. Bitbake will not automatically recompile after menuconfig. Menuconfig does not invslidate the shared state cache. Try this: bitbake -c menuconfig busybox bitbake -c -f compile busybox bitbake busybox So I have done the above. That is not the question. Busybox compiles fine and the new unstripped busybox is in the .../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/ What is the new version of busybox? What is the full filename of the new recipe that you created to compile a new version of busybox? For example the old one is busybox_1.20.2.bb (in meta/recipes-core/busybox) Also, can you please paste the .bb file in the email My question is that after compiling busybox, I do bitbake -c cleansstate core-image-minimal bitbake core-image-minimal expecting that the core image generated will contain the new busybox. It does not, it contains a busybox copy that was compiled days ago, not the custom one I just compiled. Why is this? How can I force the bitbake to include the newly-compiled busybox into my minimal image? Thanks, Brian ___ 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] Busybox still old version: Still looking for a clear understanding of an old mystery.
On Wed, Jan 16, 2013 at 10:23 AM, Brian Smucker b...@bsmucker.eu.org wrote:
Hi,
The version of busybox is the same. I've just temporarily done a bitbake -c
menuconfig to change one of the options, recompiled using the custom config
that's generated, and now I want to force its inclusion into
core-image-minimal.
I see. I think that is a bit unorthodox. (Mostly because I have never
tried it. Is it even supposed to work like you describe? I suppose
not. But that aside ...)
If I were doing this, I would create a busybox bbappend in my meta
layer and override the danny stock do_prepare_config() (in
meta/recipes-core/busybox/busybox.inc)
96 do_prepare_config () {
97 sed -e 's#@DATADIR@#${datadir}#g' \
98 ${WORKDIR}/defconfig ${S}/.config
99 sed -i -e '/CONFIG_STATIC/d' .config
100 echo # CONFIG_STATIC is not set .config
101 for i in 'CROSS' 'DISTRO FEATURES'; do echo ### $i; done \
102 ${S}/.config
103 sed -i -e '${configmangle}' ${S}/.config
104 if test ${DO_IPv4} -eq 0 test ${DO_IPv6} -eq 0; then
105 # disable networking applets
106 mv ${S}/.config ${S}/.config.oe-tmp
107 awk 'BEGIN{net=0}
108 /^# Networking Utilities/{net=1}
109 /^#$/{if(net){net=net+1}}
110 {if(net==2$0 !~ /^#/$1){print(# $1 is not
set)}else{print}}' \
111 ${S}/.config.oe-tmp ${S}/.config
112 fi
113 }
Thanks,
Brian
On 1/16/2013 6:13 AM, Autif Khan wrote:
On Tue, Jan 15, 2013 at 6:57 PM, Brian Smucker b...@bsmucker.eu.org
wrote:
Hi Rudolf,
On 1/15/2013 3:28 PM, Rudolf Streif wrote:
Brian,
What are you exactly referring to as new version? The package version
that bitbake builds is defined by the recipe, through the version
designation in the recipe's file name or through explicitly setting PV.
I think what you are trying to do is to modify the busybox configuration
and then recompile and package. Bitbake will not automatically recompile
after menuconfig. Menuconfig does not invslidate the shared state cache.
Try
this:
bitbake -c menuconfig busybox
bitbake -c -f compile busybox
bitbake busybox
So I have done the above. That is not the question. Busybox compiles
fine
and the new unstripped busybox is in the
.../yocto/tmp/work/armv4t-poky-linux-gnueabi/busybox-1.20.2-r2/busybox-1.20.2/
What is the new version of busybox?
What is the full filename of the new recipe that you created to
compile a new version of busybox? For example the old one is
busybox_1.20.2.bb (in meta/recipes-core/busybox)
Also, can you please paste the .bb file in the email
My question is that after compiling busybox, I do
bitbake -c cleansstate core-image-minimal
bitbake core-image-minimal
expecting that the core image generated will contain the new busybox. It
does not, it contains a busybox copy that was compiled days ago, not the
custom one I just compiled.
Why is this? How can I force the bitbake to include the newly-compiled
busybox into my minimal image?
Thanks,
Brian
___
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] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)
On Thu, Jan 3, 2013 at 10:45 AM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 03/01/2013 15:24, Autif Khan wrote: On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 02/01/2013 20:27, Autif Khan wrote: On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan autif.ml...@gmail.com wrote: On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: Hi all, Autif, I've been working to support .NET development on Linux over the past few days. There is a Visual Studio plugin, MonoTools for Visual Studio which provides support for local and remote debugging of .NET applications with Mono. This requires a remote stub to be running on the target platform, monotools-server. I've created a recipe to build monotools-server, which in turn required me to pull in Openembedded Legacy recipes for mono-xsp and gtk-sharp. As it stands I'm now able to build an X enabled image for the Raspberry Pi and remote-debug some simple Windows Forms .NET applications within the Visual Studio IDE. Recipes are hosted here in 'recipes-mono' g...@git.assembla.com:ciseco-eve.meta-eve.git I could not git clone the repo. Apologies. I should have given you the public r/o link. Originally I was trying to avoid modifying meta-mono, adding .bbappends into my own meta-eve layer instead, but since my last post to you I found I couldn't build against the current HEAD of Yocto due to some odd file location issues which I couldn't overlay. (i.e. it didn't seem to be able to pick up the patches where you had them - although was fine with an older commit of the Yocto core). As a result I've moved the original meta-mono patches that weren't being picked up by bitbake and merged my additions into a fork of meta-mono which is here: git://git.assembla.com/ciseco-eve.meta-mono.git Got it. I scanned thru the code and saw what you did to re-organize the directory structure. When I get back, I will see if I can build libGDI+ and mono with denzil (I am stuck with denzil for reasons beyond my control, or until I find a show stopping bug in denzil for our project - unlikely) Meanwhile, I have no questions about changes for gk-sharp, mono, mono-xsp and monotools-server. Good oh. Presumably, you will take care of the TODO: This needs fixing properly and needs to be revisited in mono_version.bb - I definitely do not want unstripped binaries on my distribution - presumably, this was needed for some debugging and is not meant to be checked into production. Ah yes. I'd forgotten about that. I shall habe to revisit why that was erroring. I could not understand the purpose of libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch - could you please help me understand what prompted these seemingly non trivial changes. Yes there seems to be a problem building libGDI against libpng15. It seems a known issue: https://github.com/mono/libgdiplus/pull/4 Everything else looks good. Good oh I'm coming up the curve on Git, as I migrate from mainly Subversion use. Can I issue a pull request to you or some such? Yes, a pull request should work. Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses. If the license is different for monotools-server or mono-xsp or gtk-sharp, you will likely have to submit a patch for README file too. Even otherwise, section 4 in README needs to be updated. If you have any tasks left - please add them to section 10. Will double check this. I am waiting for feedback from the monotools-server people on their license as there's nothing explicit in their source. Will wait for that. Might affect the README I'll give them another nudge once I've worked our what's going on with the stripping, commit to my fork and then try to work out how to send you a pull req. The guidelines for the Yocto project are very similar to other FOSS projects including the Linux kernel. They are outlined here: https://wiki.yoctoproject.org/wiki/Contribution_Guidelines I used the following as a guide when I have submitted my patches in the past. This is for the Linux kernel, adapt as appropriate for meta-mono. http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/ Please submit separate patches for each of the recipes (presumably there are no changes to the mono/libGDI+ recipes) Please add me to the To: recipient (I filter a lot of PATCH related traffic) - this should allow the emails to be caught by the filter instead of archiving. In case I do not respond within 72 hours, please email me with a gentle reminder :-) I have not had the opportunity to integrate patches just yet, please bear with me in case I screw up. Thanks again for contributing! PS #1: If you do not want to go thru the hassle - please email me the tar.gz as an attachment and I will check it in directly - a bad side effect of this would
Re: [yocto] how to add a new environment in poky
On Tue, Sep 4, 2012 at 11:15 PM, Wangdawei kyle.wangda...@huawei.com wrote:
Hi
I need to add a new environment that LD_LIBRARY_PATH when I use my
own external toolchain .
I add 1 line in external-toolchain.inc “LD_LIBRARY_PATH =.
${EXTERNAL_TOOLCHAIN}/i586-target-linux-gnu/lib:”,but there is no
effect.when I used this toolchain to compile , there also isn’t this value ,
so I want to ask how to add a environment in poky ? the run.compile.xxx
script can get the value ?
I do not use external toolchains, so I can not provide a quick answer.
However, this has come up before - several times.
Please search the mailing list archives for external toolchain integration.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Create a .bb for my aplication
On Tue, Sep 4, 2012 at 1:14 PM, Raul Rosetto Munoz munoz0r...@gmail.com wrote:
Hello,
I have some files that compose my application, and I want to put this files
in the /home/prjs folder, I know That I need to install the prjs folder
and the other files in this folder.
What I dont know first, How to create a .bb file!
I am not sure what you mean. Do you mean that if you create a .bb
file, how to include it in your image?
And another question.
I saw that if I do some things like this:
install -m 0644 ${WORKDIR}/fstab ${D}${sysconfdir}/fstab
I will copy the file fstab in /etc/ folder.
How I can know that {sysconfdir} correspond to /etc/ folder?
these are in poky/meta/conf/bitbake.conf
And If it is correct how to know for what /home/ folder correspond {???}.
If they do not exist in bitbake.conf, you should use a local variable
in your recipe or local.conf.
plz Can some one try to tell me???
Thanks For All Help!
--
Raul Rosetto Muñoz
___
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] IMAGE_FSTYPES - what formats are supported?
Is the list of values for IMAGE_FSTYPES documented somewhere? Searching though the documentation shows references to it, but not a list of values that are supported. meta/classes/image_types.bbclass look for IMAGE_TYPES ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On Tue, May 22, 2012 at 7:43 AM, jfabernathy jfaberna...@gmail.com wrote: when testing an image using runqemu qemux86, can you get networking to work?? mine comes up disabled. I want to test an application that requires Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] modify a kernel patch
On Tue, May 8, 2012 at 3:20 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: For anyone following along (all one of them), Frans and I have this working now. It was a missing export of GUILT_BASE. I just sent a patch to the list for it. Thanks! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] When bitbake core-image-sato-sdk, Error: Function failed: do_kernel_configme. Who can explain Bruce Ashfield's solution? thank you!
On Fri, May 4, 2012 at 12:10 PM, jack woaili...@hotmail.com wrote: Hello, all! When bitbake core-image-sato-sdk, I was puzzled by such errors: NOTE: package linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4: task do_kernel_configme: Started ERROR: Function failed: do_kernel_configme (see /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 for further information) ERROR: Logfile of failure stored in: /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 Log data follows: | ERROR: Function failed: do_kernel_configme (see /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/log.do_kernel_configme.18778 for further information) | [INFO] doing kernel configme | /home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/temp/run.do_kernel_configme.18778: line 92: :/home/jackie/esdc/poky/scripts:/home/jackie/esdc/poky/build/tmp/work/esdc2012-poky-linux/linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4/linux/scripts/util: No such file or directory NOTE: package linux-yocto-3.0.23+git1+59314a3523e360796419d76d78c6f7d8c5ef2593_1+63c65842a3a74e4bd3128004ac29b5639f16433f-r4: task do_kernel_configme: Failed ERROR: Task 760 (/home/jackie/esdc/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_kernel_configme) failed with exit code '1' Waiting for 2 active tasks to finish: 0: gcc-cross-4.6.3+svnr184847-r23 do_compile (pid 14631) 1: eggdbus-native-0.6-r3 do_compile (pid 18130) I googled and found Bruce Ashfield's solution: In the meantime, if you remove the kern-tools-native_git.bbappend from the meta-kernel-dev layer, the AUTOREV setting will be removed, and you won't pull in tools that are too new for the matching kernel. But where is the kern-tools-native_git.bbappend and meta-kernel-dev? I am newer to yocto, who can help me? There is no kern-tools-native_git.bbappend in what I could find. Can you please include your conf/bblayers.conf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using meta repositories from OpenEmbedded and Yocto projects
Hi, Can I re-use the meta-openembedded git repositories from openembedded.org and steve sakoman's meta-sakoman repositories (contains support for the Gumstix Overo board), and check it out inside a checkout of the yocto poky git repository, to take advantage of the latest yocto and openembedded recipes and build it for the Gumstix Overo board? for example: poky meta-openembedded (from git://git.openembedded.org/meta-openembedded) meta-openembedded-contrib (from git://git.openembedded.org/meta-openembedded-contrib) meta-sakoman.git (from git://www.sakoman.com/git/meta-sakoman) Short answer - Yes :-) At least the first one is used in meta-chromium I've used OpenEmbedded before, and this is my first time with Yocto, and I see a bunch of meta-* repositories, and was wondering if including them inside the main poky folder was the way to go, to add additional support from various sources. Long answer - Don't forget to add these meta layers in conf/bblayers.conf Best regards, Elvis Dowson ___ 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] [PATCH 2/2] yocto-bsp: clarify help with reference to meta-intel
+ NOTE: For x86- and x86_64-based BSPs, the generated BSP assumes the + presence of the of the meta-intel layer. Ensure the meta-intel layer + is present and added to bblayers.conf. Unless I am really mis-reading this I think presence of the of the should just be presence of the Oh wow. :-) There is an illusion like this (attached jpeg) attachment: illusion.jpg___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] to build the opencv lib
On Tue, Apr 24, 2012 at 6:13 AM, 沈华明@qq 446257...@qq.com wrote:
Hi,
I want to build the opencv lib into yocto,but I have no idea to do it. I
have copyed a opencv_1.0.0.bb file
into my layer,and after I do :bitbake opencv.,it comes the error:Nothing
PROVIDES 'swig'(but )
The recipe is the following,
You can not just copy a recipe - if it has dependencies, then you need
to copy those recipes too.
OR - the simpler thing to do
Add the entire meta layer to bblayers.conf
DESCRIPTION = Opencv : The Open Computer Vision Library
HOMEPAGE = http://sourceforge.net/projects/opencvlibrary;
SECTION = libs
PRIORITY = optional
LICENSE = GPLv2
PR = r3
DEPENDS = libtool swig swig-native python jpeg zlib libpng tiff glib-2.0
#RDEPENDS_${PN} = python jpeg zlib libpng tiff glib-2.0
This is where the recipe says that it depends on swig and you likely
do not have swig in any of your meta layers. Chances are - you can get
swig from the same place you got the recipe for opencv
SRC_URI = ${SOURCEFORGE_MIRROR}/opencvlibrary/opencv-${PV}.tar.gz \
file://debian/010_enable_static.diff \
file://debian/010_ffmpeg_linking.diff \
file://debian/010_fix_optimisations.diff \
file://debian/010_m4_syntax.diff \
file://debian/010_makefile_syntax.diff \
file://debian/010_python_cspec.diff \
file://debian/020_python_linking.diff \
file://debian/030_install_hook.diff \
file://debian/050_rebootstrap.diff \
file://debian/100_amd64.diff \
file://debian/100_static_inline.diff \
file://debian/100_ffmpeg_updates.diff \
file://debian/110_dc1394.diff \
file://debian/120_header_warnings.diff \
file://debian/200_documentation.diff \
file://debian/200_examples_makefile.diff \
file://debian/210_openmp_compilation.diff \
file://debian/300_fix_segfault_in_window_gtk.diff \
inherit distutils-base autotools pkgconfig
EXTRA_OECONF = --disable-debug --without-gtk --without-python
--disable-apps az_python_cspec=${STAGING_INCDIR}/${PYTHON_DIR}
export BUILD_SYS
export HOST_SYS
do_configure() {
gnu-configize
cp ${STAGING_DATADIR}/libtool/config.{sub,guess} autotools
oe_runconf
}
PACKAGES += python-opencv
python populate_packages_prepend () {
cv_libdir = bb.data.expand('${libdir}', d)
cv_libdir_dbg = bb.data.expand('${libdir}/.debug', d)
do_split_packages(d, cv_libdir, '^lib(.*)\.so$', 'lib%s-dev', 'OpenCV %s
development package', extra_depends='${PN}-dev', allow_links=True)
do_split_packages(d, cv_libdir, '^lib(.*)\.la$', 'lib%s-dev', 'OpenCV %s
development package', extra_depends='${PN}-dev')
do_split_packages(d, cv_libdir, '^lib(.*)\.a$', 'lib%s-dev', 'OpenCV %s
development package', extra_depends='${PN}-dev')
do_split_packages(d, cv_libdir, '^lib(.*)\.so\.*', 'lib%s', 'OpenCV %s
library', extra_depends='', allow_links=True)
}
FILES_${PN}-doc += ${datadir}/opencv/
FILES_${PN} = ${bindir}
FILES_${PN}-dbg += ${libdir}/.debug
FILES_${PN}-dev = ${includedir} ${libdir}/pkgconfig
DESCRIPTION_python-opencv = Python bindings to opencv
FILES_python-opencv = ${PYTHON_SITEPACKAGES_DIR}/*
RDEPENDS_python-opencv = python-core
SRC_URI[md5sum] = 146a05005f2d2c16c4ee10ebd7f1dd58
SRC_URI[sha256sum] =
3a6ee888e4dd4ab7f2bc80d046688c099c6a95d1267af554b7c8f1543b66f21e
Thanks~
___
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] [PATCH 1/1] Fixed the URL for git repo for meta-openembedded
Signed-off-by: Autif Khan aut...@gmail.com --- README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index 5fafd9d..9f441f5 100644 --- a/README +++ b/README @@ -10,7 +10,7 @@ URI: git://git.openembedded.org/openembedded-core branch: master revision: HEAD -URI: git://git.openembedded.net/meta-openembedded +URI: git://git.openembedded.org/meta-openembedded branch: master revision: HEAD -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using and auditing kernel config fragments
For some reason which I cannot work out, the rt2800usb options are removed (rather then disabled) from the yocto kernel config, i.e., if I run 'bitbake -c menuconfig linux-yocto', there is very little under Drivers-Net-WLAN. If I run menuconfig in the devshell, there are lots more WLAN drivers available, including the rt2800. Under Device Drivers - Network device support - Wireless LAN, You have to enable Ralink driver support to see the options for CONFIG_RT2800USB It is not under Device Drivers - Network device support - Wireless LAN It is under Device Drivers - Network device support - Wireless LAN - Ralink driver support ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] using and auditing kernel config fragments
For some reason which I cannot work out, the rt2800usb options are removed (rather then disabled) from the yocto kernel config, i.e., if I run 'bitbake -c menuconfig linux-yocto', there is very little under Drivers-Net-WLAN. If I run menuconfig in the devshell, there are lots more WLAN drivers available, including the rt2800. Under Device Drivers - Network device support - Wireless LAN, You have to enable Ralink driver support to see the options for CONFIG_RT2800USB It is not under Device Drivers - Network device support - Wireless LAN It is under Device Drivers - Network device support - Wireless LAN - Ralink driver support I forgot to mention - Under Networking Support - Wireless, you need to enable cfg80211 AND msc80211 (Generic IEEE 802.11 Netowrking Stack) Then the Ralink driver support shows up under Wireless LAN ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.2 changelog
Here is the list as it stands: https://wiki.yoctoproject.org/wiki/Release_1.2_Changes (Note that changes in 1.1.1 have been separated out and should probably just be deleted, hopefully I didn't miss any). I was pleasantly surprised when unionfs showed up in the kernel - it is not in the list though. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
Hi Autif, thanks a lot for providing the answer here. Since no one is showing any objections here, I updated the wiki page with your answer (https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). Please let me know if there is any suggestions or concerns. This rather narrow answer is only useful if you are running a MatchBox desktop. There are many other deployment scenarios which would require a different approach. That is true. However, All over the Yocto Project's website - the common bitbake commands for an image is either core-image-minimal or core-image-sato. (core-image-sato-sdk also uses matchbox). minimal does not start any app - not counting daemons and gettys If the user chooses another window manager - they are/should be on their own. I just assumed that we are not trying to document the init process (bootloader, kernel, initrd, inittab, init.d etc) We are trying to answer a less experienced developer to replace the default window manager with their own app There is a chance that I am not aware of the default application being other than matchbox. Can you please provide me some counter example? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
Hi Song, I thought that I already updated the wiki. It seems like you created an extra page. _scripts is missing from the link. It should be there. Source: https://wiki.yoctoproject.org/wiki/Category:FAQ What I added days ago: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts What you added (which I think should be deleted): https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup Agree? On Tue, Apr 3, 2012 at 4:34 PM, Liu, Song song@intel.com wrote: Hi Autif, thanks a lot for providing the answer here. Since no one is showing any objections here, I updated the wiki page with your answer (https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). Please let me know if there is any suggestions or concerns. Song -Original Message- From: Autif Khan [mailto:autif.ml...@gmail.com] Sent: Thursday, March 29, 2012 4:56 PM To: Liu, Song Cc: yocto@yoctoproject.org Subject: Re: [yocto] How to change the startup application I got a question about how to change the startup application with Yocto for images generated with Yocto. And I googled it and landed on this page: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup _scripts. Pretty good, someone was thinking about the same thing. But this page turns out to be empty. It seems that we need to get better than this. I'm wondering if someone could update this wiki page or if the information is somewhere else... I do not know of if the information is elsewhere - I had to find this information for my project Here is my stab at it (already updated the wiki): Q: How do I change and add startup scripts? A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. Of course, if you have your own meta-layer, append the matchbox-session-sato_0.1.bb recipe. Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable 'exec matchbox-window-manager ...' Don't forget to run your app as a background process For example, the following code will start the fifteen game: #matchbox-desktop # Lines containing feature-[foo] are removed at build time if the machine # doesn't have the feature foo. #START_APPLETS=showdesktop,windowselector #END_APPLETS=clock,battery,systray,startup-notify,notify #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone #matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets $END_APPLETS /usr/games/fifteen exec matchbox-window-manager -theme Sato -use_desktop_mode decorated -use_cursor $SHOWCURSOR $@ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
I got a question about how to change the startup application with Yocto for images generated with Yocto. And I googled it and landed on this page: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts. Pretty good, someone was thinking about the same thing. But this page turns out to be empty. It seems that we need to get better than this. I'm wondering if someone could update this wiki page or if the information is somewhere else... I do not know of if the information is elsewhere - I had to find this information for my project Here is my stab at it (already updated the wiki): Q: How do I change and add startup scripts? A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. Of course, if you have your own meta-layer, append the matchbox-session-sato_0.1.bb recipe. Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable 'exec matchbox-window-manager ...' Don't forget to run your app as a background process For example, the following code will start the fifteen game: #matchbox-desktop # Lines containing feature-[foo] are removed at build time if the machine # doesn't have the feature foo. #START_APPLETS=showdesktop,windowselector #END_APPLETS=clock,battery,systray,startup-notify,notify #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone #matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets $END_APPLETS /usr/games/fifteen exec matchbox-window-manager -theme Sato -use_desktop_mode decorated -use_cursor $SHOWCURSOR $@ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Graphics Acceleration on crownbay - 1.2M2 + meta-intel tip
I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = web-webkit for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
Minor correction to the subject - I am using 1.2M3, not 1.2M2 On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan autif.ml...@gmail.com wrote: I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = web-webkit for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
On Wed, Mar 21, 2012 at 4:23 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2012-03-21 at 16:15 -0400, Autif Khan wrote: Minor correction to the subject - I am using 1.2M3, not 1.2M2 On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan autif.ml...@gmail.com wrote: I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = web-webkit for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? When I tested video using gst-launch, I saw the same thing, which was due to a missing libva-tpi. The latest commit in meta-intel added that and fixed the problem for me. commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b Author: Tom Zanussi tom.zanu...@intel.com Date: Mon Mar 12 19:57:29 2012 -0500 ia32-base: add libva display dependencies to emgd xserver I did a build today with tip - I have confirmed that I have this in the source. What files should have been added to the root filesystem image as a reult of adding libva-tpi, libva-glx and libva-egl? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
Minor correction to the subject - I am using 1.2M3, not 1.2M2 On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan autif.ml...@gmail.com wrote: I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = web-webkit for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? When I tested video using gst-launch, I saw the same thing, which was due to a missing libva-tpi. The latest commit in meta-intel added that and fixed the problem for me. commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b Author: Tom Zanussi tom.zanu...@intel.com Date: Mon Mar 12 19:57:29 2012 -0500 ia32-base: add libva display dependencies to emgd xserver I did a build today with tip - I have confirmed that I have this in the source. What files should have been added to the root filesystem image as a reult of adding libva-tpi, libva-glx and libva-egl? You should see those shared libraries in /usr/lib I think that I do: root@crownbay:/usr/lib# ls -l *libva* lrwxrwxrwx1 root root19 Mar 21 17:38 libva-egl.so.1 - libva-egl.so.1.0.12 -rwxr-xr-x1 root root 3040 Mar 21 17:07 libva-egl.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-glx.so.1 - libva-glx.so.1.0.12 -rwxr-xr-x1 root root 14868 Mar 21 17:07 libva-glx.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-tpi.so.1 - libva-tpi.so.1.0.12 -rwxr-xr-x1 root root 3856 Mar 21 17:07 libva-tpi.so.1.0.12 lrwxrwxrwx1 root root19 Mar 21 17:38 libva-x11.so.1 - libva-x11.so.1.0.12 -rwxr-xr-x1 root root 28476 Mar 21 17:07 libva-x11.so.1.0.12 lrwxrwxrwx1 root root15 Mar 21 17:38 libva.so.1 - libva.so.1.0.12 -rwxr-xr-x1 root root 68816 Mar 21 17:07 libva.so.1.0.12 The older image did not have egl, glx and tpi However, when I execute gst-launch -v playbin2 uri=file:///media/hdd/BBB.ogv I get a lot of There may be a timestamping problem, or this computer is too slow. warnings. Attached are the logs created by the above command. Is there something else that needs to be done? log.gz Description: GNU Zip compressed data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Graphics Acceleration on crownbay - 1.2M3 + meta-intel tip
Minor correction to the subject - I am using 1.2M3, not 1.2M2 On Wed, Mar 21, 2012 at 4:14 PM, Autif Khan autif.ml...@gmail.com wrote: I am trying to get hardware accelerated graphics (video in particular) to work on my crownbay based hardware. I have EMGD 1.10 driver integrated and working. The evidence for this is that when I use glxgears (form mesa-demos) I get 115 fps instead of 4-5 fps. This is good, however, when I go over to the web2 browser (enabled by defining WEB = web-webkit for recipe task-core-apps-x11-pimlico) - I do not get graphics acceleration for javascript graphics. I also do not get graphics acceleration when I watch an MP4 movie. I get 2-3 fps instead of the standard 25 or 29 fps. This was not the case when Yocto used EMGD 1.8 driver - video worked fine - I am not sure about accelerated javascript based graphics in browser as I was not as far ahead in the project. Is this a known issue? When I tested video using gst-launch, I saw the same thing, which was due to a missing libva-tpi. The latest commit in meta-intel added that and fixed the problem for me. commit 162f3d1d3c538d7582a5e81205a9cdab74125b2b Author: Tom Zanussi tom.zanu...@intel.com Date: Mon Mar 12 19:57:29 2012 -0500 ia32-base: add libva display dependencies to emgd xserver I did a build today with tip - I have confirmed that I have this in the source. What files should have been added to the root filesystem image as a reult of adding libva-tpi, libva-glx and libva-egl? You should see those shared libraries in /usr/lib I think that I do: root@crownbay:/usr/lib# ls -l *libva* lrwxrwxrwx 1 root root 19 Mar 21 17:38 libva-egl.so.1 - libva-egl.so.1.0.12 -rwxr-xr-x 1 root root 3040 Mar 21 17:07 libva-egl.so.1.0.12 lrwxrwxrwx 1 root root 19 Mar 21 17:38 libva-glx.so.1 - libva-glx.so.1.0.12 -rwxr-xr-x 1 root root 14868 Mar 21 17:07 libva-glx.so.1.0.12 lrwxrwxrwx 1 root root 19 Mar 21 17:38 libva-tpi.so.1 - libva-tpi.so.1.0.12 -rwxr-xr-x 1 root root 3856 Mar 21 17:07 libva-tpi.so.1.0.12 lrwxrwxrwx 1 root root 19 Mar 21 17:38 libva-x11.so.1 - libva-x11.so.1.0.12 -rwxr-xr-x 1 root root 28476 Mar 21 17:07 libva-x11.so.1.0.12 lrwxrwxrwx 1 root root 15 Mar 21 17:38 libva.so.1 - libva.so.1.0.12 -rwxr-xr-x 1 root root 68816 Mar 21 17:07 libva.so.1.0.12 The older image did not have egl, glx and tpi However, when I execute gst-launch -v playbin2 uri=file:///media/hdd/BBB.ogv I get a lot of There may be a timestamping problem, or this computer is too slow. warnings. Attached are the logs created by the above command. Is there something else that needs to be done? Hmm, looks like the acceleration isn't kicking in. Is that a supported format for emgd accelaration? - I've been testing with 1080p .h264 videos, http://www.bigbuckbunny.org/index.php/download/, maybe if you could try that so we know we're on the same page. I was hoping that Ogg Video is supported. I tried the H.264 (BBB stands for bigbuck bunny, I got these movies from an earlier email from you). But I am getting another error - ERROR: pipeline doesn't want to preroll. Do I need some other codec or some library? Are there licensing implications of using H.264? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding test files to an image
Suppose I want to build the meta-intel/meta-sugarbay image and also include
some video and audio files into the /home/root directory to facilitate
testing of the video and audio players.
Can I include these files in a recipe somewhere?
I use the recipe at the end of this message to include whatever I
want. This recipe has to be added to the image - I have a custom
image, so it goes in there. I am sure a recipe can be added to
something in local.conf - I just do not know that variable. My guess
it is IMAGE_IMSTALL += mypics.
Regardless ...
mypics-1.0.tar.gz contains a file called COPYING and its mds5um on the
2nd line. It can be replaced with a license from common licenses
directory - but at the time when I wrote this recipe, I did not know
how to do that. Anything that goes in there ends up in
/home/root/mypics.
It can probably be tweaked to look better - I am sure SRC_URI line is
not perfect. But it seems to work between Edison to master
For larger files - like video worth 200MB or so, I just store them on
a hard disk and mount manually on /media/hdd or where-ever. Not that
it wont work in this recipe, just that it would take longer to build
the image etc.
All the best. Hopefully, this will get you started in the right direction.
LICENSE = MyLic
LIC_FILES_CHKSUM = file://COPYING;md5=697172b05e4bff0a2421579697ba5653
MY_DESTINATION = /home/root/mypics
SRC_URI = file://mypics-1.0/mypics-1.0.tar.gz
do_install_append() {
install -d ${D}${MY_DESTINATION}
install -m 0644 ${S}/* ${D}${MY_DESTINATION}
}
PR = r0
FILES_${PN} += ${MY_DESTINATION}/*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding test files to an image
On Thu, Mar 8, 2012 at 4:43 PM, jfabernathy jfaberna...@gmail.com wrote:
On 03/08/2012 04:33 PM, Rudolf Streif wrote:
Jeff,
Use hyphen instead of underscore for the subdirectory SRC_URI:
SRC_URI = file://myvideos-1.0/myvideos-1.0.tar.gz
and of course for the subdirectory in the subdirectory where the recipe is
located. The file fetcher copies the entire path
myvideos-1.0/myvideos-1.0.tar.gz to ${WORKDIR}.
Rudi
that didn't solve the problem. I still get file not found errors. The
videos are unpack to WORKDIR, but the do_install is looking for them in S.
install -d
/build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/image/home/root/myvideos
install -m 0644
/build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/myvideos-1.0/*
/build/sugarbay-master/tmp/work/x86_64-poky-linux/myvideos-1.0-r0/image/home/root/myvideos
I think I need to control where the do_unpack puts the files.
Just a dumb thought, but I have been bitten many times by it.
please try bitbake myvideos -c cleansstate
then bitbake myvideos to build the recipe.
Alternatively, you can of course rev up the PR everytime you change
the recipe. But that is cumbersome.
And yes, I forgot to mention in my previous mail that the
mypics-1.0.tar.gz is located in
meta-autif/recipes-autif/mypics/mypics-1.0/mypics-1.0.tar.gz
As Rudolf suggested - bitbake is a bit finickey about '-' and '_'
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] iptables not building on master
I was working with M2 until recently and had to switch to master. After I switched to master, I tried to bitbake core-image-sato for machine crownbay. The build fails with the following error: unknown type name '__aligned_u64' The file in question is extenstions/libxt_pkttypes.c After a bit of investigation (thanks Khem) it seems like instead of /usr/include/linux/types.h, the include/linux/types.h from iptables source is being included. These a bit incompatible - specifically - the definition for __aligned_u64 is not in the latter. I am building core-image-sato for qemux86 and will report when the build reaches that point. Is this a known issue? *** This issue should be hitting anyone doing a clean build on master. Or at the very least someone who builds iptables recipe*** I looked at the recent change (post M2) that iptables was updated to 1.2.12.2 (from 1.2.12.1). There was a patch included for extensions/GNUmakefile which does not build check target. I looked at what it does and realized that someone more experienced that I am should look into this. Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] iptables not building on master
I love working with master: work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says: configure: error: Could not find pam/pam-devel, please install the needed packages. It seems like pam/pam-dev is needed in the target environment and not in the host environment. Although, iptables seem to have built. I can't imagine how it will be affected by meta-intel and meta-crownbay - they do not do anything with iptables. Trying to build core-image-minimal for crownbay now. Will report when done. On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan autif.ml...@gmail.com wrote: I was working with M2 until recently and had to switch to master. After I switched to master, I tried to bitbake core-image-sato for machine crownbay. The build fails with the following error: unknown type name '__aligned_u64' The file in question is extenstions/libxt_pkttypes.c After a bit of investigation (thanks Khem) it seems like instead of /usr/include/linux/types.h, the include/linux/types.h from iptables source is being included. These a bit incompatible - specifically - the definition for __aligned_u64 is not in the latter. I am building core-image-sato for qemux86 and will report when the build reaches that point. Is this a known issue? *** This issue should be hitting anyone doing a clean build on master. Or at the very least someone who builds iptables recipe*** I looked at the recent change (post M2) that iptables was updated to 1.2.12.2 (from 1.2.12.1). There was a patch included for extensions/GNUmakefile which does not build check target. I looked at what it does and realized that someone more experienced that I am should look into this. Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] iptables not building on master
Interesting - core image minimal builds fine - it does not actually build iptables. So the point is moot. I did a clean build for core-image-sato and it failed at the same place for the same error. I am no sure how meta-intel + meta-crownbay can interact with iptables - there is no recipe for iptables in meta-intel anywhere. Tom - If you have the bandwidth - can you please see if you can replicate my woes. I do not know anyone else who is on master and crownbay. If there - please let me know if things work for you. This broke for me when I moved from M2 to master. Thanks Autif On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan autif.ml...@gmail.com wrote: I love working with master: work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says: configure: error: Could not find pam/pam-devel, please install the needed packages. It seems like pam/pam-dev is needed in the target environment and not in the host environment. Although, iptables seem to have built. I can't imagine how it will be affected by meta-intel and meta-crownbay - they do not do anything with iptables. Trying to build core-image-minimal for crownbay now. Will report when done. On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan autif.ml...@gmail.com wrote: I was working with M2 until recently and had to switch to master. After I switched to master, I tried to bitbake core-image-sato for machine crownbay. The build fails with the following error: unknown type name '__aligned_u64' The file in question is extenstions/libxt_pkttypes.c After a bit of investigation (thanks Khem) it seems like instead of /usr/include/linux/types.h, the include/linux/types.h from iptables source is being included. These a bit incompatible - specifically - the definition for __aligned_u64 is not in the latter. I am building core-image-sato for qemux86 and will report when the build reaches that point. Is this a known issue? *** This issue should be hitting anyone doing a clean build on master. Or at the very least someone who builds iptables recipe*** I looked at the recent change (post M2) that iptables was updated to 1.2.12.2 (from 1.2.12.1). There was a patch included for extensions/GNUmakefile which does not build check target. I looked at what it does and realized that someone more experienced that I am should look into this. Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] USB touchscreen integration
On Thu, Mar 1, 2012 at 12:30 AM, Khem Raj raj.k...@gmail.com wrote: On 02/24/2012 10:04 AM, Autif Khan wrote: I have a touchscreen made by AUO. It came with a driver which I have written a recipe for and it seems to be compiling and when the touchscreen is detected, the driver seems to be loading and controlling the touchscreen. (Its not under the control of hid_core driver). It shows up in /proc/bus/input/devices I: Bus=0003 Vendor=03eb Product=201c Version=1503 N: Name=pixcir_hid_mt_v2.0 P: Phys= S: Sysfs=/devices/pci:00/:00:17.0/:01:00.0/:02:02.0/usb3/3-1/3-1:1.0/input/input4 U: Uniq= H: Handlers=mouse0 B: PROP=0 B: EV=b B: KEY=400 0 0 0 0 0 0 0 0 0 0 B: ABS=65 3 It shows up as /dev/input/mouse0 tslib handles /dev/input/touchscreen0 can you modify the driver ? After struggling, I realized that enabling events and events debug, I can get more information - which lead me to an issue with the LCD driver provided by the vendor. Vendor is supporting me since. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] apt-native_0.7.14.bb failed
Hi, I tried to build image with: bitbake -k core-image-sato, with http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2 but it failed, here is error message: --- NOTE: Running task 5229 of 5288 (ID: 82, /home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb, do_install) NOTE: package apt-native-0.7.14-r5: task do_install: Started ERROR: Function 'do_install_base' failed (see /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 for further information) ERROR: Logfile of failure stored in: /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 Log data follows: | oe_libinstall: cd bin | oe_libinstall: install -d /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/image/home/jingzhe/yocto/edison-6.0-build/tmp/sysroots/i686-linux/usr/lib// | ERROR: oe_libinstall: unable to locate shared library | ERROR: Function 'do_install_base' failed (see /home/jingzhe/yocto/edison-6.0-build/tmp/work/i686-linux/apt-native-0.7.14-r5/temp/log.do_install.28773 for further information) NOTE: package apt-native-0.7.14-r5: task do_install: Failed ERROR: Task 82 (/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb, do_install) failed with exit code '1' ERROR: '/home/jingzhe/yocto/poky-edison-6.0/meta/recipes-devtools/apt/apt-native_0.7.14.bb' failed -- does anybody know how to solve it? To help understand the context, can you please include the the MACHINE variable. Its in conf/local.conf ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] USB touchscreen integration
I have a touchscreen made by AUO. It came with a driver which I have written a recipe for and it seems to be compiling and when the touchscreen is detected, the driver seems to be loading and controlling the touchscreen. (Its not under the control of hid_core driver). It shows up in /proc/bus/input/devices I: Bus=0003 Vendor=03eb Product=201c Version=1503 N: Name=pixcir_hid_mt_v2.0 P: Phys= S: Sysfs=/devices/pci:00/:00:17.0/:01:00.0/:02:02.0/usb3/3-1/3-1:1.0/input/input4 U: Uniq= H: Handlers=mouse0 B: PROP=0 B: EV=b B: KEY=400 0 0 0 0 0 0 0 0 0 0 B: ABS=65 3 It shows up as /dev/input/mouse0 While this is great, I am not sure how to wire this up with X so that the mouse is actually functional on the screen. A quick search at yocto wiki resulted in nothing, and google's search in site:yoctoproject.org also resulted in somewhat irrelevant results. I am using poky master on machine crownbay. X is running very well on an LVDS monitor. Keyboard and mouse run fine when externally connected. This query is limited to wiring a USB touchscreen with yocto. I am not sure what the next steps are. Please help! Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-mono is released
meta-mono has been released. I have tested it on x86 and ARM successfully and on PPC and MIPS unsuccessfully. I will work on those architectures and time becomes available. If someone prefers that they need mono for MIPS or PPC immediately, please email me and I will see what I can do. comments and patches are welcome. The README for meta-mono is attached below: 1) Intro 2) Dependencies 3) Maintainer(s) Patch policy 4) Copyright 5) Current State - x86 6) Current State - ARM 7) Current State - MIPS 8) Current State - PPC 9) Current State - alpha, amd64, hppa, ia64, s390 sparc 10) TODO 1) Intro meta-mono is an OpenEmbedded layer that builds mono runtime and mono libraries to allow users to run .NET applications under linux built using OE. For more info about mono, see mono project's website. For more info on OpenEmbedded, see OE's website. 2) Dependencies On the host: The host system must have the following packges: gcc g++ patch diffstat texi2html texinfo cvs subversion gawk chrpath make libgl1-mesa-dev libglu1-mesa-dev libsdl1.2-dev git libxml-parser-perl bison gettext flex unzip rpm2cpio On the target: So far, Windows Forms applications have been tested under Sato. Mono does not require Sato, it does require X if you want to run Windows Forms applications. While mono can run w/o X, that recipe is not supported currently. It is unlikely to be supported. 3) Maintainer(s) Patch policy Autif Khan (autif.ml...@gmail.com) autif on #yocto on freenode Send a patch or tar.gz file as attachment to the maintainer. 4) Copyright MIT/GPLv2 - following the lead of libgdiplus and mono 5) Current State - x86: Works Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono and core-image-mono-sdk for qemux86 and crownbay. The maintainer has also tested mono using all the runtime tests and few library tests that come with mono. The maintainer has also tested one Windows Forms application. 6) Current State - ARM: Works Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono for qemuarm. The maintainer has tested one Windows Forms application. 7) Current State - MIPS: Minor issues need to be resolved Maintainer uses Yocto/OE/Poky as his build environment. He has built core-image-mono for qemumips. A Windows Forms application fails to execute. More investigation is needed, if there is an interest in getting mono to work perfectly on MIPS, please contact the maintainer. 8) Current State - PPC: Does not build Maintainer uses Yocto/OE/Poky as his build environment. The build for core-image-mono for qemuppc fails. If there is an interest in getting mono to work perfectly on PPC, please contact the maintainer. 9) Current State - alpha, amd64, hppa, ia64, s390 sparc: Unknown When qemu provided by Yocto supports one of these machines, the maintainer will support these architectures. 10) TODO 10.1) see if mono works for amd64, seems like qemux86-64 is available 10.2) investigate why windows forms apps dont run on MIPS 10.2) investigate why compilation fails for PPC 10.3) run mono runtime tests for ARM 10.4) run mono runtime tests for MIPS 10.5) run mono runtime tests for PPC 10.6) run mono library tests for ARM 10.7) run mono library tests for MIPS 10.8) run mono library tests for PPC 10.9) write recipes to create packages for runtime tests 10.10) write recipes to create packages for mscorlib library tests 10.11) write recipes to create packages for System.dll library tests 10.12) try mono on beagleboard (email maintainer when you do this, he will thank you) 10.13) write a recipe for windows forms app ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono is released
On Wed, Feb 22, 2012 at 1:25 PM, Autif Khan autif.ml...@gmail.com wrote: meta-mono has been released. I have tested it on x86 and ARM successfully and on PPC and MIPS unsuccessfully. I will work on those architectures and time becomes available. If someone prefers that they need mono for MIPS or PPC immediately, please email me and I will see what I can do. At this point of time, I am using github for hosting the source. Michael Halstead is setting me up with git.yoctoproject The code will be moved over to git.yoctoproject in the next few days. I neglected to include the link in the previous email. Here are the relevant links: http://www.openembedded.org/wiki/LayerIndex meta-mono is listed under software support layers http://github.com/KokoFitClub/meta-mono This URI will very soon be replaced with git.yoctoproject.org Of course, Layer Index will be updated when this is done. Once again, please use it and let me know if something does not work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono is released
meta-mono has been released. I have tested it on x86 and ARM successfully and on PPC and MIPS unsuccessfully. I will work on those architectures and time becomes available. If someone prefers that they need mono for MIPS or PPC immediately, please email me and I will see what I can do. At this point of time, I am using github for hosting the source. Michael Halstead is setting me up with git.yoctoproject The code will be moved over to git.yoctoproject in the next few days. Things move at light speed apparently. All the code is available at git.yoctoproject and github. Only git.yoctoproject is authoritative, the code at github will be removed soon. Layer Index has been updated to reflect this. http://www.openembedded.org/wiki/LayerIndex Source is in git: git://git.yoctoproject.org:meta-mono.git http://git.yoctoproject.org (under Yocto MetaData Layers) I neglected to include the link in the previous email. Here are the relevant links: http://www.openembedded.org/wiki/LayerIndex meta-mono is listed under software support layers http://github.com/KokoFitClub/meta-mono This URI will very soon be replaced with git.yoctoproject.org Of course, Layer Index will be updated when this is done. Once again, please use it and let me know if something does not work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS fails to find an existing package
Hello,
On Thu, 2012-02-16 at 10:26 +0530, Joshua Immanuel wrote:
Can you please explain little bit more on what INSANE_SKIP_${PN} =
dev-so does. I don't find any documentation on it.
I guess, it suppresses the warnings stating that an non-dev package
contains symlink. This is the warning I got, when I packaged protobuf
for yocto
In the e-mail I mentioned that if you are using M2 1.2 (means the
milestone 2 of version 1.2). 1,2 final will be released sometime in
the next few weeks/months.
Sometime between 1.1 and 1.2 M2 - the behavior has been changed where
the warning you described below has been changed to an error - thereby
- the said .so files are not actually included.
This does not apply if you are using 1.0 or 1.1 (not sure about 1.1
myself - I jumped from 1.0 to 1.2 M2)
Eventually - if/when you will be using a newer release of yocto - your
recipe will fail to work as expected - unless you have that insane
skip.
WARNING: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
protobuf path
'/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so'
WARNING: QA Issue: protobuf:
/work/core2-poky-linux/protobuf-2.4.1-r1/packages-split/protobuf/usr/lib/libprotobuf.so
contains probably-redundant RPATH /usr/lib
Adding the line INSANE_SKIP_${PN} = dev-so suppressed the above
warnings.
This is correct.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS fails to find an existing package
Hello Khem Raj,
On Wed, 2012-02-15 at 07:28 -0800, Khem Raj wrote:
the .a files are going into -static package and I guess
there is .so and not .so.X which means .so goes into
-dev package and hence your libharu package is empty
so you have to redirect the files into correct package
with the help of FILES_${PN} = libharu.so etc.
You were right. Thanks for the tip.
Adding FILES_${PN} = ${libdir}/lib*.so made bitbake to create an
non-empty libharu package thereby fixing the problem.
Heads up - if you are using 1.2 M2 - you may have to add the following
line in your recipe:
INSANE_SKIP_{PN} = dev-so
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error occurs,
you can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
I have a similar questions. If the error occurs and the console log
information scrolls too far to get back to, how do I find the error log file
then? I know what directory all the logs will be, but is there an easy way to
find the one with the error??
This is true - I set my terminal scrollback to lines to avoid this.
May be that error line should be displayed both before and after the log.
I will see if I can find where this happens and create a patch. But
that will have to wait until after ELC 2012.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building your own UI
This may be a dumb question, but I'll ask anyway. Suppose you have a project where you need a very custom user interface. Not just a series of applications that appear on a desktop like you see in sato, or Gnome, or KDE. Basically your application becomes the UI. I can see 2 approaches to this: Start with core-image-minimal and add the packages you need to support GFX, X11, and your application plus dependencies. Take core-image-sato and change the applications to be your subtasks , and the look-and-feel of the desktop. What are the considerations of both approaches? Is one better, or easier than the other? How would you do this in Yocto? Where do you look for information you need to accomplish this? We are still in the very early stages of architecture design and development For now we are leaning towards keeping everything that comes with core-image-sato and writing a full screen app on top of it. Likely to be written in .NET (mono). A prototype (proof of concept) has been successfully developed :-) As I said - still in very early stages of arch/design and dev. So things may still change. If it is okay to jump in an comment, I was going to ask the same question at some point. The need to have the application as the main UI or shell to the system is important for branding. Launching sato or other desktop would not be desirable. As an example, Windows uses Explorer.exe as the shell, but can be replaced with any application. Windows was architected this way. It would be nice to have similar architecture here, but I know it is easier said than done. As you said this is early in design. We do have a lot of open questions that we will answer in good time: 1) Should the application be executed as root or as some user or as nobody 2) Should we trim the image? (we are not short on space or ram) 3) Aforementioned - should the app run from inittab or rcS.d or something else We will figure out these things when we are on that bridge. I do have a question - you have provided the example of Windows - where explorer is the shell and can be changed. However, there is no argument here - what are the clear (no brainer) or subjective arguments for one versus the other. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto in Virtualbox
On Wed, Feb 8, 2012 at 3:14 AM, cnxsoft cnxs...@cnx-software.com wrote: Hi, I have build x86 qemu image using bitbake -k core-image-sato following the instructions given at http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html I'm running Ubuntu 11.10 in VirtualBox 4.1.6. When I run qemu, qemu starts apparently fine, but the qemu window stays black. So I'm suspecting that either it does not work in Virtualbox or I may have tochange some settings in qemu (e.g. -vga vmware). Here's the output: runqemu qemux86 Continuing with the following parameters: KERNEL: [/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin] ROOTFS: [/home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3] FSTYPE: [ext3] Setting up tap interface under sudo Acquiring lockfile for tap0... Starting distccd... Running qemu... /home/jaufranc/edev/edison-6.0-build/tmp/sysroots/i686-linux/usr/bin/qemu -kernel /home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/bzImage-qemux86.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda /home/jaufranc/edev/edison-6.0-build/tmp/deploy/images/core-image-minimal-qemux86.ext3 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 Enabling opengl So, what is the problem? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
Chatted with TomZ on #yocto on freenode IRC, it looks like I did not
perform the steps in section II from README in
meta-intel/meta-crownbay. It is likely that that's what I am missing.
On Tue, Feb 7, 2012 at 10:12 AM, autif khan autif.ml...@gmail.com wrote:
I am bitbaking core image sato for machine corwnbay (with the emgd
driver) and the emgd-driver-bin recipe seems to fail.
Here is the error. I searched the archives, but could not find anything.
Please advise.
Here is the output for bitbake -b
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb
NOTE: Running task 1 of 12 (ID: 4,
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
do_fetch)
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Started
ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
ERROR: Logfile of failure stored in:
/ssd/autif/M2/crb/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r8/temp/log.do_fetch.31621
Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['bzr',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['cvs',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['git',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['hg',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['osc',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['p4',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svk',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svn',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: Trying Upstream
| ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Failed
ERROR: Task 4
(/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb,
do_fetch) failed with exit code '1'
ERROR:
'/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.8.bb'
failed
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
I am bitbaking core image sato for machine corwnbay (with the emgd driver) and the emgd-driver-bin recipe seems to fail. Here is the error. I searched the archives, but could not find anything. Please advise. It looks like the problem may be forgetting to carry out the steps in section 'II. Special notes for building the meta-crownbay BSP layer' in the README. Note that this is no longer necessary if you use master - the emgd-driver-bin recipe has been upgraded to do the steps there automatically, which is now possible because it uses the LICENSE_FLAGS, but which does mean you need to set the LICENSE_FLAGS_WHITELIST as mentioned in the new README for crownbay in master. I can confirm that using the master branch is the way to go to make this easy. I documented my test of it at : https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_setup_Intel.C2.AE_Atom.E2.84.A2_Processor_E6xx_based_system_for_media_playback.3F Confirmed - after following all the steps in section II of the README in meta-intel/meta-crownbay - the build worked. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building your own UI
This may be a dumb question, but I'll ask anyway. Suppose you have a project where you need a very custom user interface. Not just a series of applications that appear on a desktop like you see in sato, or Gnome, or KDE. Basically your application becomes the UI. I can see 2 approaches to this: Start with core-image-minimal and add the packages you need to support GFX, X11, and your application plus dependencies. Take core-image-sato and change the applications to be your subtasks , and the look-and-feel of the desktop. What are the considerations of both approaches? Is one better, or easier than the other? How would you do this in Yocto? Where do you look for information you need to accomplish this? We are still in the very early stages of architecture design and development For now we are leaning towards keeping everything that comes with core-image-sato and writing a full screen app on top of it. Likely to be written in .NET (mono). A prototype (proof of concept) has been successfully developed :-) As I said - still in very early stages of arch/design and dev. So things may still change. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch the kernel before it is built?
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}:
SRC_URI += file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff
PR = r3
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
Fond the bug - it was a problem in the recipe
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
I was missing the ${PN} at the end.
Bruce - Thank you for all the help :-)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build Error
Here is what I have - I started with a minimal ubuntu server and the following command seens to get all the dependencies - the last few (bison, flex and unzip) are not required - but are required for other stuff I am working on. I hope this helps with the documentation. sudo apt-get install -y gcc g++ patch diffstat texi2html texinfo cvs subversion gawk chrpath make libgl1-mesa-dev libglu1-mesa-dev libsdl1.2-dev git libxml-parser-perl bison gettext flex unzip On Mon, Feb 6, 2012 at 11:44 AM, Sean Liming sean_lim...@sjjmicro.com wrote: Found the problem - missing package - libxml-parser-perl. It is not part of the setup. For any future reference, here is the fix: $sudo apt-get install libxml-parser-perl Ubuntu was a fresh install. I should have checked the docs in progress, which calls it out at the end. Regards, Sean Liming Owner SJJ Embedded Micro Solutions, LLC. Tel: 714-970-7523 / Cell: 858-774-3176 -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Sean Liming Sent: Sunday, February 05, 2012 11:21 PM To: 'Khem Raj' Cc: yocto@yoctoproject.org Subject: Re: [yocto] Build Error Searching further there seems to be different patches for perl-native for Ubuntu 10.04. Not sure what needs to be applied here. Regards, Sean -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Sean Liming Sent: Sunday, February 05, 2012 11:05 PM To: 'Khem Raj' Cc: yocto@yoctoproject.org Subject: Re: [yocto] Build Error How would I check if perl-native is staged? The intltool.inc has the updated Rudolf. Regards, Sean -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Sunday, February 05, 2012 10:30 PM To: Sean Liming Cc: yocto@yoctoproject.org Subject: Re: [yocto] Build Error On Sun, Feb 5, 2012 at 8:01 PM, Sean Liming sean_lim...@sjjmicro.com wrote: @ autif- thank you for the tar file. Placed it in the downloads folder and the error doesn't appear. I added the two lines to the local.conf folder INHERIT += own-mirrors SOURCE_MIRROR_URL = http://autobuilder.yoctoproject.org/pub/sources/; I am not sure how to resolve the lib-xml-parser for intltool issue based on the post. checking for perl... /usr/bin/perl checking for perl = 5.8.1... 5.12.4 checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool ERROR: oe_runconf failed it should not be getting perl from your build but from the native sysroot. is perl-native staged ? Regards, Sean Liming Owner SJJ Embedded Micro Solutions, LLC. Tel: 714-970-7523 / Cell: 858-774-3176 -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Sunday, February 05, 2012 4:00 PM To: Sean Liming Cc: yocto@yoctoproject.org Subject: Re: [yocto] Build Error On Sun, Feb 5, 2012 at 2:27 PM, Sean Liming sean_lim...@sjjmicro.com wrote: Did I miss configure something? Wrong python version? There was a post about the dash vs. bash shell. I am not sure what shell is supposed to be using: you could add something like below to your local.conf INHERIT += own-mirrors SOURCE_MIRROR_URL = http://autobuilder.yoctoproject.org/pub/sources/; that should help a bit ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ 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] How do I patch the kernel before it is built?
I could not find a way to patch the kernel source before its is built.
I promise to update the Yocto wiki's How do I section when I have a
working solution for the following :-)
This should be covered in the existing documentation and also the
more general bitbake/oe-core docs.
Here is what I am trying to do:
1) Patch the kernel (add VID/PID to hid_ignore_list in
drivers/hid/hid-core.c and also to add the VID/PID to .h file)
2) Build the kernel - no change here - standard kernel build
3) Build a kernel module
I have a meta layer where I am keeping my changes. I am guessing that I
need to:
a) write a bbappend file to accomplish #1
b) write a recipe to accomplish #3
I have written recipes before, but just for libraries and autotools
based applications. Not for a kernel module. If there is a recipe out
there for some other module, I would be happy to steal from it.
Please advise how I can go about patching the kernel and if there is a
It's just like any other package. If your changes are simple, then
generating patches and putting them on the SRC_URI via a bbappend in
your layer is all you need. If you have complex changes, there are options
to manage them via git or via feature descriptions.
I tried this - attached at the end of this email are my bbappend file
and my patches, when the recipe is bitbaked, it does not actually
apply the patch.
On a similar note - there seems to be a file in
meta/recipes-kernel/linux/linux-yocto called
tools-perf-no-scripting.patch
However, it does not seem to be used anywhere - is this just crud or I
am missing something? I was hoping to cheat off of the recipe that
uses it.
recipe for a kernel module - please point me to it.
Darren validated and updated the kernel module example, so he'd probably
got this closer at hand than I do.
See the hello-mod example under meta/recipes-kernel/hello-mod
Thank you for this recipe - it seems like this is exactly what I was
looking for. I will cheat off of this as soon as I can patch my
kernel.
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}:
SRC_URI += file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff
PR = r3
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
P A T C H
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
Taking a look at this (while I was cutting and pasting), this should
be in in the
a 'linux-yocto' subdirectory if you want bitbake to pickup the patch and make
it
available to the linux-yocto recipe.
i.e.
~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
that part is
automatic.
I tried this just now - here is what happens:
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://drivers/hid/file.diff
Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://linux-yocto/drivers/hid/file.diff
Result - my diff files are copied in a directory called linux-yocto in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
These patches are not applied in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
Here is what the work directory looks like
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
ls
git license-destdir linux linux-crownbay-standard-build linux-yocto temp
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
I have attached the original set of files as a tar gzip.
(and yes, I see 'edison' was the branch now)
Yes, I am using Yocto 1.0 - very soon I will migrate to M2 - pending
tasks at hand :-)
Cheers,
Bruce
cat hid-core.c.diff
--- linux.orig/drivers/hid/hid-core.c 2012-01-31 16:44:44.152001877 -0500
+++ linux/drivers/hid/hid-core.c 2012-01-31 16:46:34.608001870 -0500
@@ -1839,6 +1839,8 @@
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_1_PHIDGETSERVO_20) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK,
USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PIXCIR, USB_DEVICE_ID_PIXCIR) },
{ }
};
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
cat hid-ids.h.diff---
Re: [yocto] How do I patch the kernel before it is built?
I could not find a way to patch the kernel source before its is
built.
I promise to update the Yocto wiki's How do I section when I have a
working solution for the following :-)
This should be covered in the existing documentation and also the
more general bitbake/oe-core docs.
Here is what I am trying to do:
1) Patch the kernel (add VID/PID to hid_ignore_list in
drivers/hid/hid-core.c and also to add the VID/PID to .h file)
2) Build the kernel - no change here - standard kernel build
3) Build a kernel module
I have a meta layer where I am keeping my changes. I am guessing that
I need to:
a) write a bbappend file to accomplish #1
b) write a recipe to accomplish #3
I have written recipes before, but just for libraries and autotools
based applications. Not for a kernel module. If there is a recipe out
there for some other module, I would be happy to steal from it.
Please advise how I can go about patching the kernel and if there is
a
It's just like any other package. If your changes are simple, then
generating patches and putting them on the SRC_URI via a bbappend in
your layer is all you need. If you have complex changes, there are
options
to manage them via git or via feature descriptions.
I tried this - attached at the end of this email are my bbappend file
and my patches, when the recipe is bitbaked, it does not actually
apply the patch.
On a similar note - there seems to be a file in
meta/recipes-kernel/linux/linux-yocto called
tools-perf-no-scripting.patch
However, it does not seem to be used anywhere - is this just crud or I
am missing something? I was hoping to cheat off of the recipe that
uses it.
recipe for a kernel module - please point me to it.
Darren validated and updated the kernel module example, so he'd
probably
got this closer at hand than I do.
See the hello-mod example under meta/recipes-kernel/hello-mod
Thank you for this recipe - it seems like this is exactly what I was
looking for. I will cheat off of this as soon as I can patch my
kernel.
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}:
SRC_URI += file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff
PR = r3
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
P A T C H
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
Taking a look at this (while I was cutting and pasting), this should
be in in the
a 'linux-yocto' subdirectory if you want bitbake to pickup the patch and
make it
available to the linux-yocto recipe.
i.e.
~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
that part is
automatic.
I tried this just now - here is what happens:
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://drivers/hid/file.diff
Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
If you get a fetcher failire, you have it in the wrong place.
Note: this has nothing to do with the kernel and is a general
bitbake/oe-core question.
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://linux-yocto/drivers/hid/file.diff
Interesting. I've never had to specify linux-yocto in my SRC_URIs,
so something strange it going on here.
Does anyone else have ideas here ?
Result - my diff files are copied in a directory called linux-yocto in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
These patches are not applied in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
Here is what the work directory looks like
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
ls
git license-destdir linux linux-crownbay-standard-build linux-yocto
temp
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
I have attached the original set of files as a tar gzip.
I'll take them for a spin.
(and yes, I see 'edison' was the branch now)
Yes, I am using Yocto 1.0 - very soon I will migrate to M2 - pending
tasks at hand :-)
I'll have to dig up a 1.0 tree, since I don't have anything of that
vintage available to me.
But I know that patched worked then, and am absolutely sure that it
works in 1.1 and master.
OK, I switched to M2 release and now, I have a different error:
Case - diff files are in recipes/linux/linux-yocto, SRC_URI is
file://drivers/hid/hid-core.c.diff
Result - ERROR: Function 'Fetcher
Re: [yocto] How do I patch the kernel before it is built?
\ I could not find a way to patch the kernel source before its is
built.
I promise to update the Yocto wiki's How do I section when I have a
working solution for the following :-)
This should be covered in the existing documentation and also the
more general bitbake/oe-core docs.
Here is what I am trying to do:
1) Patch the kernel (add VID/PID to hid_ignore_list in
drivers/hid/hid-core.c and also to add the VID/PID to .h file)
2) Build the kernel - no change here - standard kernel build
3) Build a kernel module
I have a meta layer where I am keeping my changes. I am guessing
that
I need to:
a) write a bbappend file to accomplish #1
b) write a recipe to accomplish #3
I have written recipes before, but just for libraries and autotools
based applications. Not for a kernel module. If there is a recipe
out
there for some other module, I would be happy to steal from it.
Please advise how I can go about patching the kernel and if there
is
a
It's just like any other package. If your changes are simple, then
generating patches and putting them on the SRC_URI via a bbappend in
your layer is all you need. If you have complex changes, there are
options
to manage them via git or via feature descriptions.
I tried this - attached at the end of this email are my bbappend file
and my patches, when the recipe is bitbaked, it does not actually
apply the patch.
On a similar note - there seems to be a file in
meta/recipes-kernel/linux/linux-yocto called
tools-perf-no-scripting.patch
However, it does not seem to be used anywhere - is this just crud or I
am missing something? I was hoping to cheat off of the recipe that
uses it.
recipe for a kernel module - please point me to it.
Darren validated and updated the kernel module example, so he'd
probably
got this closer at hand than I do.
See the hello-mod example under meta/recipes-kernel/hello-mod
Thank you for this recipe - it seems like this is exactly what I was
looking for. I will cheat off of this as soon as I can patch my
kernel.
R E C I P E
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$ cat
linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}:
SRC_URI += file://linux/drivers/hid/hid-core.c.diff \
file://linux/drivers/hid/hid-ids.h.diff
PR = r3
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux$
P A T C H
autif@fpbm:~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux/drivers/hid$
Taking a look at this (while I was cutting and pasting), this should
be in in the
a 'linux-yocto' subdirectory if you want bitbake to pickup the patch
and
make it
available to the linux-yocto recipe.
i.e.
~/data/yocto/poky-edison-6.0/meta-koko/recipes/linux/linux-yocto/drivers/hid
And don't use 'linux-yocto' in your file:// reference on the SRC_URI,
that part is
automatic.
I tried this just now - here is what happens:
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://drivers/hid/file.diff
Result: Fetcher failure for URL: 'file://drivers/hid/hid-core.c.diff
If you get a fetcher failire, you have it in the wrong place.
Note: this has nothing to do with the kernel and is a general
bitbake/oe-core question.
Case - patch is in linux/linux-yocto/drivers/hid, SRC_URI ref is
file://linux-yocto/drivers/hid/file.diff
Interesting. I've never had to specify linux-yocto in my SRC_URIs,
so something strange it going on here.
Does anyone else have ideas here ?
Result - my diff files are copied in a directory called linux-yocto in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3
These patches are not applied in
tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3/linux
Here is what the work directory looks like
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
ls
git license-destdir linux linux-crownbay-standard-build linux-yocto
temp
autif@fpbm:~/ssd/minimal/tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r3$
I have attached the original set of files as a tar gzip.
I'll take them for a spin.
(and yes, I see 'edison' was the branch now)
Yes, I am using Yocto 1.0 - very soon I will migrate to M2 - pending
tasks at hand :-)
I'll have to dig up a 1.0 tree, since I don't have anything of that
vintage available to me.
But I know that patched worked then, and am absolutely sure that it
works in 1.1 and master.
OK, I switched to M2 release and now, I have a different error:
Case - diff files are in recipes/linux/linux-yocto, SRC_URI is
file://drivers/hid/hid-core.c.diff
Re: [yocto] Build Error
I also attached the corresponding .done file however, since its size was 0, it was not attached - dont forget to add a .done file too. On Sun, Feb 5, 2012 at 6:24 PM, autif khan autif.ml...@gmail.com wrote: It seems like wget http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz return a 500 - Internal server error. Does not look like you did anything wrong. However, I do not know a workaround. I have attached these files from my downloads directory. You can copy these files in yours and it should get you by for now. On Sun, Feb 5, 2012 at 5:27 PM, Sean Liming sean_lim...@sjjmicro.com wrote: I am new developer to Yocto and embedded Linux in general Host machine: i3 with 4GB RAM OS: Ubuntu 11.10 64-bit I am following the online quick start guide, and looks like the end of bitbake runs into several errors: ERROR: Task 1136 (/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/contacts_git.bb, do_configure) failed with exit code '1' ERROR: '/home/sean/poky-edison-6.0/meta/recipes-devtools/icon-naming-utils/icon-naming-utils-native_0.8.7.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.1.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-support/libfm/libfm_0.1.14.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-gnome/gnome/gnome-vfs_2.24.4.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-support/vte/vte_0.24.3.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/puzzles/oh-puzzles_git.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-connectivity/connman/connman-gnome_0.5.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/tasks_0.19.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/dates_git.bb' failed ERROR: '/home/sean/poky-edison-6.0/meta/recipes-sato/pimlico/contacts_git.bb' failed Looking back at the build process, one error calls out a package that cannot be downloaded: http://tango.freedesktop.org/releases/icon-naming-utils-0.8.7.tar.gz I have attached errors some of the log files. The common error appears to be oe_runconf failed. Did I miss configure something? Wrong python version? There was a post about the dash vs. bash shell. I am not sure what shell is supposed to be using: The instructions say run sudo dpkg-reconfigure dash and say no. Nothing in the message popup says what is the shell. Thanks for any help. Regards, Sean ___ 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] Gaku music player
Hi Jim, I would appreciate if you could add some information to the How do I section in the wiki. I am not there yet, but I also need audio and video on crownbay in about 4-8 weeks. Thanks for getting to the bottom of this Autif On Fri, Feb 3, 2012 at 3:21 PM, James Abernathy jfaberna...@gmail.com wrote: On Fri, Feb 3, 2012 at 11:02 AM, James Abernathy jfaberna...@gmail.com wrote: I tried all the different mixer options on the Crownbay. It's just not very loud. I'll try an amplifier, but with earphones, it almost not loud enough to hear. I don't remember other Linux's having this issue. Could there be something else software wise? The good news is the built-in GUI Music and Video players work with the H.264 files I've tested as well as the command line stuff. Also got the glxgears works as well. Jim A To close this one out. The Crownbay seems to have a line level out only and not a port that supports headphones and line level. Once I put minimal Line in level amplfication, the audio works as expected. Thanks for the help. It's good to see nice integration in Yocto of video and music players that actually plays the the H.264 and MP3 files. Jim A ___ 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] How do I patch the kernel before it is built?
I could not find a way to patch the kernel source before its is built. I promise to update the Yocto wiki's How do I section when I have a working solution for the following :-) Here is what I am trying to do: 1) Patch the kernel (add VID/PID to hid_ignore_list in drivers/hid/hid-core.c and also to add the VID/PID to .h file) 2) Build the kernel - no change here - standard kernel build 3) Build a kernel module I have a meta layer where I am keeping my changes. I am guessing that I need to: a) write a bbappend file to accomplish #1 b) write a recipe to accomplish #3 I have written recipes before, but just for libraries and autotools based applications. Not for a kernel module. If there is a recipe out there for some other module, I would be happy to steal from it. Please advise how I can go about patching the kernel and if there is a recipe for a kernel module - please point me to it. Thank you Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libtool version mismatch
I have been working on writing a recipe for mono. I have successfully written one for lbgdiplus and am making headway with mono. Mono comes with libtool version 2.2.6, Yocto uses 2.4 After do_configure(), when do_complie() is being executed, I am getting the following error for the following command: Command: /bin/sh ./libtool --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/home/autif/data2/nosync/dev/yocto/kokosdk/tmp/sysroots/crownbay -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\hans_bo...@hp.com\ -DPACKAGE_URL=\\ -DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DPARALLEL_MARK=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -O2 -pipe -g -feliminate-unused-debug-types -g -mno-tls-direct-seg-refs -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c Error: | libtool: Version mismatch error. This is libtool 2.4, but the | libtool: definition of this LT_INIT comes from libtool 2.2.6. | libtool: You should recreate aclocal.m4 with macros from libtool 2.4 | libtool: and run autoconf again. | make[3]: *** [allchblk.lo] Error 63 Here is how LT_INIT is defined in aclocal.m4: # LT_INIT([OPTIONS]) # -- AC_DEFUN([LT_INIT], [AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT AC_BEFORE([$0], [LT_LANG])dnl AC_BEFORE([$0], [LT_OUTPUT])dnl AC_BEFORE([$0], [LTDL_INIT])dnl m4_require([_LT_CHECK_BUILDDIR])dnl dnl Autoconf doesn't catch unexpanded LT_ macros by default: m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl m4_pattern_allow([^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$])dnl dnl aclocal doesn't pull ltoptions.m4, ltsugar.m4, or ltversion.m4 dnl unless we require an AC_DEFUNed macro: AC_REQUIRE([LTOPTIONS_VERSION])dnl AC_REQUIRE([LTSUGAR_VERSION])dnl AC_REQUIRE([LTVERSION_VERSION])dnl AC_REQUIRE([LTOBSOLETE_VERSION])dnl m4_require([_LT_PROG_LTMAIN])dnl dnl Parse OPTIONS _LT_SET_OPTIONS([$0], [$1]) # This can be used to rebuild libtool when needed LIBTOOL_DEPS=$ltmain # Always use our own libtool. LIBTOOL='$(SHELL) $(top_builddir)/libtool' AC_SUBST(LIBTOOL)dnl _LT_SETUP # Only expand once: m4_define([LT_INIT]) ])# LT_INIT What changes should be made to the auto tools files to fix this? Thanks! Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool version mismatch
On Tue, Jan 24, 2012 at 10:44 AM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Jan 24, 2012 at 7:18 AM, autif khan autif.ml...@gmail.com wrote:
Error:
| libtool: Version mismatch error. This is libtool 2.4, but the
| libtool: definition of this LT_INIT comes from libtool 2.2.6.
| libtool: You should recreate aclocal.m4 with macros from libtool 2.4
| libtool: and run autoconf again.
| make[3]: *** [allchblk.lo] Error 63
this says it all and we do that regeneration automatically for recipes
which inherit autotools
It seems that way, but I can not explain the following behavior.
1) I can grep autoreconf in log.do_configure
2) When I add do_configure_prepend() {autoreconf --force --install
-Wcorss} this issue seems to go away.
So, I am confused, but not lost - as it seems like this updated recipe
seems to work.
I have attached logs for before and after the changes specified in 2 (above)
you need to post your recipes for someone to look at what you are doing
Still a work in progress:
SUMMARY = An Open Source implementation of the Microsoft's .NET Framework
DESCRIPTION = This is part of the Mono project - http://mono-project.com;
HOMEPAGE = http://mono-project.com;
BUGTRACKER = http://bugzilla.xamarin.com/;
SECTION = devel
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING.LIB;md5=58d09de7e50ecdbafcf97e7eb5d0c34a
SRC_URI = http://download.mono-project.com/sources/mono/mono-${PV}.tar.bz2 \
file://mono-2.6.7/mono/mini/Makefile.in.1.diff \
file://mono-2.6.7/mono/profiler/Makefile.in.2.diff
inherit autotools pkgconfig
DEPENDS =+ libgdiplus
PR = r0
SRC_URI[md5sum] = cc8b7bf061bd11fbd0fcc1c95eb79d34
SRC_URI[sha256sum] =
ae21a997d72e2fb8ea88644c87ab52471e9c97117b937e205ea1835b5a028ce4
EXTRA_OECONF += --disable-mcs-build mono_cv_uscore=no
--with-tls=pthread --with-sigaltstack=no
do_configure_prepend() {
autoreconf -Wcross --verbose --install --force || bbnote mono
failed to autoreconf
}
do_compile_prepend() {
ln -s i586-poky-linux-libtool libtool
}
mono.temp.tar.gz
Description: GNU Zip compressed data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libtool version mismatch
On Tue, Jan 24, 2012 at 12:09 PM, Khem Raj raj.k...@gmail.com wrote:
On Tue, Jan 24, 2012 at 8:13 AM, autif khan autif.ml...@gmail.com wrote:
do_configure_prepend() {
autoreconf -Wcross --verbose --install --force || bbnote mono
failed to autoreconf
}
do_compile_prepend() {
ln -s i586-poky-linux-libtool libtool
}
get rid of above these are not needed when recipes inherit autotools
see if you need to copy over some of m4 macros that is what you
need to do in do_configure_prepend if needed.
Can you point me to an existing recipe that already does something
similar? I am not sure what I am looking for.
Thanks for all the help!
Autif
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-sato-directdisk
I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).
I perform the following broad steps:
1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde
If grub install passed, I copy the following to /mnt/target/boot/grub/grub.cfg
set default=0
set timeout=30
menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}
Thats it - this boots for me.
Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.
All the best, do tell if this works.
On Thu, Jan 19, 2012 at 7:51 PM, James Abernathy jfaberna...@gmail.com wrote:
The README.hardware file in the poky directory talks about creating images
on 2 types of disk for the Atom based PCs like the n450. The one I've
successfully tested is the core-image-sato on a USB key. I have no luck
with the directdisk method because the image recipe doesn't exist for
core-image-minimal-directdisk or core-image-sato-directdisk.
Is there a way to put Yocto on the hard drive on a Atom PC?
Jim A
___
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] core-image-sato-directdisk
On Fri, Jan 20, 2012 at 11:13 AM, Jim Abernathy jfaberna...@gmail.com wrote:
On 01/20/2012 09:16 AM, autif khan wrote:
I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).
I perform the following broad steps:
1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the
atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3
/mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde
If grub install passed, I copy the following to
/mnt/target/boot/grub/grub.cfg
set default=0
set timeout=30
menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}
Thats it - this boots for me.
Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.
All the best, do tell if this works.
This worked fine for me. one typo in step (5) ext3 and not text3, but these
are good instructions. How do we get them put into the README.hardware
instead of the directdisk section that doesn't work anymore.
Yup, I wrote then off the cuff, I am glad that a typo is the only
error and no major missing steps :-)
I am also glad that these steps worked for you.
Did you file a bug on this?
I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in
Thanks,
Jim Abernathy
On Thu, Jan 19, 2012 at 7:51 PM, James Abernathyjfaberna...@gmail.com
wrote:
The README.hardware file in the poky directory talks about creating
images
on 2 types of disk for the Atom based PCs like the n450. The one I've
successfully tested is the core-image-sato on a USB key. I have no luck
with the directdisk method because the image recipe doesn't exist for
core-image-minimal-directdisk or core-image-sato-directdisk.
Is there a way to put Yocto on the hard drive on a Atom PC?
Jim A
___
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] core-image-sato-directdisk
On Fri, Jan 20, 2012 at 12:15 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 20 January 2012 11:54:44 autif khan wrote: Did you file a bug on this? I have not. I am not sure I should. I am not even sure whoose call it should be weather or not this goes in README.hardware. I hope someone chimes in So I would say if any of our documentation is out-of-date or unclear, it should be fixed, no deliberation needed :) However, in Poky master, README.hardware has now been updated to remove references to the old directdisk images. It could be that we need to explicitly add something like what you have written about writing the image to a hard disk, but for the moment it is at least no longer out-of-date. At the very least a great start would be to put your instructions up as a page on the Yocto Project wiki. I have created a new link titled How Do I on the main page and for now, this is the only entry. Please take a look. https://wiki.yoctoproject.org/wiki/Main_Page https://wiki.yoctoproject.org/wiki/How_do_I Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] auto tools tagged configuration
So, I have been trying to cross compile mono and having some luck with it. When the configure script runs, it creates a libtool script which does not work well with yocto's cross compilation setup. Step 1: So, I rename this libtool as libtool.orig and Step 2: copy the libtool from tmp/sysroots/crownbay/usr/bin/crossscripts/i586-poky-linux-libtool This errors out as follows: ... ... CC debug-debugger.lo debug-debugger.c: In function ‘debugger_get_boxed_object’: debug-debugger.c:211:21: warning: variable ‘last_boxed_object’ set but not used [-Wunused-but-set-variable] ../../doltlibtool --quiet --mode=compile i586-poky-linux-gcc -m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse -c -o mdb-debug-info32.lo mdb-debug-info32.s libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[4]: *** [mdb-debug-info32.lo] Error 1 make[4]: Leaving directory `/home/autif/data2/nosync/dev/yocto/apps/mono/mono-2.6.3/mono/mini' ... ... At this point, if I delete the cross libtool and rename libtool.orig (from Step 1) back to libtool, make continues beyond this step and fails further. Again, copying yocto's libtool as done is Step 2, allows make to continue creates all the binaries and libraries. At this point the binaries can be manually copied to the target and seem to pass a lot of mono's runtime and library tests. This is great! (make install fails, but, resolution for it can wait) So, what is this tagged information can can not be infered and what can I do to mono's autoconf script to fix this? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
Here is a recipe that I using to generate a custom SDK image which I can use to natively compile mono on the target. require recipes-sato/images/core-image-sato-sdk.bb IMAGE_INSTALL += bison libtool PR=r0 bison is required and I added libtool because it was being generated by mono's autoconf (./configure) script and gave the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' If I understand correctly, yocto has a special libtool which understands how to handle '=/path/to/lib' The problem is that it looks like 'libtool' is not included in the image. I do have the libtool recipe in meta/recipes-devtools/libtool The libtool version generated by mono was 2.2.6b The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) Am I doing something wrong? If not, where is the 'libtool' in the image? Thanks Autif On Thu, Jan 5, 2012 at 4:59 PM, autif khan autif.ml...@gmail.com wrote: I talked to a couple of mono developers (kangaroo and vargaz) - the consensus is that 'auto' is hosed I am not an expert in auto tools, I just know how to configure, make, make install. I get by when I need to know my way around makefiles I am a capable C/C++ developer - please advise or point me to right resources. Thanks Autif On Thu, Jan 5, 2012 at 4:52 PM, autif khan autif.ml...@gmail.com wrote: I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
When I try to compile mono using the ADT (bitbake meta-ide-support, source the environment file and configure, followed by make), I get the same behavior. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' But then, even in this case, mono's autoconf (./configure) generated a 'libtool' instead of using the one from yocto's development environment. Please advise. Thanks Autif On Mon, Jan 9, 2012 at 3:12 PM, autif khan autif.ml...@gmail.com wrote: Here is a recipe that I using to generate a custom SDK image which I can use to natively compile mono on the target. require recipes-sato/images/core-image-sato-sdk.bb IMAGE_INSTALL += bison libtool PR=r0 bison is required and I added libtool because it was being generated by mono's autoconf (./configure) script and gave the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' If I understand correctly, yocto has a special libtool which understands how to handle '=/path/to/lib' The problem is that it looks like 'libtool' is not included in the image. I do have the libtool recipe in meta/recipes-devtools/libtool The libtool version generated by mono was 2.2.6b The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) Am I doing something wrong? If not, where is the 'libtool' in the image? Thanks Autif On Thu, Jan 5, 2012 at 4:59 PM, autif khan autif.ml...@gmail.com wrote: I talked to a couple of mono developers (kangaroo and vargaz) - the consensus is that 'auto' is hosed I am not an expert in auto tools, I just know how to configure, make, make install. I get by when I need to know my way around makefiles I am a capable C/C++ developer - please advise or point me to right resources. Thanks Autif On Thu, Jan 5, 2012 at 4:52 PM, autif khan autif.ml...@gmail.com wrote: I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
While googling, I found this link (http://mashandmish.wordpress.com/2011/04/20/crossbuilding-webkit-with-a-yocto-toolchain-part-i-glib/) Here, the author is replacing the libtool generated by autoconf (./configure script) with the one form the sysroot. i.e. ./configure cp /opt/poky/1.0/sysroots/i686-pokysdk-linux/usr/bin/i686-pokysdk-libtool libtool I did the equivalent and amazingly got the same results. I am sure I am missing something. Just not sure what. On Mon, Jan 9, 2012 at 3:45 PM, autif khan autif.ml...@gmail.com wrote: When I try to compile mono using the ADT (bitbake meta-ide-support, source the environment file and configure, followed by make), I get the same behavior. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' But then, even in this case, mono's autoconf (./configure) generated a 'libtool' instead of using the one from yocto's development environment. Please advise. Thanks Autif On Mon, Jan 9, 2012 at 3:12 PM, autif khan autif.ml...@gmail.com wrote: Here is a recipe that I using to generate a custom SDK image which I can use to natively compile mono on the target. require recipes-sato/images/core-image-sato-sdk.bb IMAGE_INSTALL += bison libtool PR=r0 bison is required and I added libtool because it was being generated by mono's autoconf (./configure) script and gave the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' If I understand correctly, yocto has a special libtool which understands how to handle '=/path/to/lib' The problem is that it looks like 'libtool' is not included in the image. I do have the libtool recipe in meta/recipes-devtools/libtool The libtool version generated by mono was 2.2.6b The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68) Am I doing something wrong? If not, where is the 'libtool' in the image? Thanks Autif On Thu, Jan 5, 2012 at 4:59 PM, autif khan autif.ml...@gmail.com wrote: I talked to a couple of mono developers (kangaroo and vargaz) - the consensus is that 'auto' is hosed I am not an expert in auto tools, I just know how to configure, make, make install. I get by when I need to know my way around makefiles I am a capable C/C++ developer - please advise or point me to right resources. Thanks Autif On Thu, Jan 5, 2012 at 4:52 PM, autif khan autif.ml...@gmail.com wrote: I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Does my build disk's filesystem make a difference?
You are better off with one of the dual boot OSes in a virtual machine that a dual boot situation where you are trying to write to NTFS from linux or trying to work with ext2fs tools from windows. I do not even know if you can create equivalent of symlinks (used extensively in yocto) on an NTFS In theory, it might work, but NTFS was not built for linux, likewise, ext4 was not meant to be used for windows. It is a bad idea. You know - unless this happens to be your master's research thesis :-) On Fri, Jan 6, 2012 at 6:53 PM, Jeff Osier-Mixon je...@jefro.net wrote: I am creating a Yocto Project build system. For various reasons, it is a dual-boot system, win7 linux (probably mint 12, haven't decided). I have a primary boot disk with both operating systems and a large secondary disk to use for build trees etc. Does the filesystem on the big secondary disk matter? Ideally I would like to be able to get to the large data disk from both operating systems. That would necessitate NTFS, as win7 does not speak ext4 reliably, but I don't want to slow my builds down. -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ 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] Trying to compile mono on target for machine crownbay
I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
I talked to a couple of mono developers (kangaroo and vargaz) - the consensus is that 'auto' is hosed I am not an expert in auto tools, I just know how to configure, make, make install. I get by when I need to know my way around makefiles I am a capable C/C++ developer - please advise or point me to right resources. Thanks Autif On Thu, Jan 5, 2012 at 4:52 PM, autif khan autif.ml...@gmail.com wrote: I bitbaked core-image-sato-sdk, copied it to the target disk and tried to build mono natively on the target machine and I got the following error: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid I am not sure why there is a leading '=' in the path. Needless to say - mono builds fine on ubuntu, so it is unlikely (not impossible) to be a mono build issue. Has anyone seen anything like this with mono or some other piece of software? Thanks Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to compile mono on target for machine crownbay
On Thu, Jan 5, 2012 at 5:17 PM, Mark Hatle mark.ha...@windriver.com wrote: On 1/5/12 3:52 PM, autif khan wrote: libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' The version of libtool you are currently using is damaged in some way. I suspect the program is falling back and trying to use either a local version or the host-system version. I am using 6.0 Edison release of yocto. Is libtool being broken a known issue for this version? The libtool located within the OE/Poky environment understands that when a = is predicating a path, it means locate the item within the sysroot at the following path. Since the error indicates it doesn't understand that concept, it appears that that version of libtool is broken. Normally the autotools class will deal with this situation for you. Simply inheriting autotools class usually does it. For now, there is no recipe for mono in yocto. There is one for a very old version of mono on OE that I have looked at. It does not work, when it is integrated in some layer. It fails with a somewhat different error (included below). So I am trying to write the recipe for mono and trying to compile it on native hardware - that would be the first step - if I can compile it natively, then I will try to cross compile it, and then I can try to write the recipe. So, I do not have a sysroot to cross compile ... It is the native root file system - the compilation happens on the target hardware. How can I figure out what the issue is with auto tools? Thanks Autif Error form mono recipe from OE: checking for preceeding underscore in symbols... configure: error: in `/home/autif/data/dev/yocto/koko/tmp/work/core2-poky-linux/mono-2.6.3-r0.1/mono-2.6.3': configure: error: cannot run test program while cross compiling ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
Another recipe question along the same path.
The following recipe does not actually put helloworld in the image -
it does not even build it.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += helloworld
The following one does.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += helloworld
I am guessing that if I have several recipes in my layer (say) hw1,
hw2, hw3 etc, I would have to use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_INSTALL += hw1 hw2 hw3 etc
However, I am sure there is a way to ties these up with
IMAGE_FEATURE variable.
Can you please help me with setting up my recipes so that all the
hello world apps are included when I use the following recipe.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += helloworld
I am guessing that I would have to tell the hw1 recipe that it is a
helloworld feature. How do I go about doing this?
Here it is for reference:
DESCRIPTION = hello world app
SECTION = autif
LICENSE = SomeLic
LIC_FILES_CHKSUM = file://COPYING;md5=178c09540123ca26c1b9c1ccbfbcde87
PR = r0
SRC_URI = file://COPYING \
file://helloworld.c
S = ${WORKDIR}
do_compile () {
${CC} helloworld.c -o helloworld
}
do_install () {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
Thanks again!
Autif
On Wed, Dec 28, 2011 at 3:43 PM, autif khan autif.ml...@gmail.com wrote:
Must be the hangover from the holidays!
I typed the path as you suggested (I did replace recipes-core with
recipes-sato), but I must have had a type somewhere and it did not
work and gave the same error. I then tried the relative path - which I
copied and pasted - instead of typing and it worked. So I assumed
thats what it must have been.
Now, I have the following as my recipe and it works just fine. As I
said - must be the hangover from the holidays.
require recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += helloworld
Thanks again
Autif
On Wed, Dec 28, 2011 at 3:31 PM, Chris Larson clar...@kergoth.com wrote:
On Wed, Dec 28, 2011 at 1:22 PM, autif khan autif.ml...@gmail.com wrote:
Thats right. Accounting for the relative, path, the following recipe
seems to works.
require ../../../meta/recipes-sato/images/core-image-sato.bb
IMAGE_FEATURES += helloworld
That's not what I was referring to. You don't need the full relative
path. It will automatically search BBPATH if you require a relative
path. if you do require recipes-sato/images/core-image-sato.bb, it
will search your layers and find it.
--
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] How to require image recipe from another layer?
Thats right. Accounting for the relative, path, the following recipe seems to works. require ../../../meta/recipes-sato/images/core-image-sato.bb IMAGE_FEATURES += helloworld Thanks for the help Autif On Wed, Dec 28, 2011 at 3:12 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Dec 28, 2011 at 1:06 PM, autif khan autif.ml...@gmail.com wrote: I have the following problem and I am not sure how to resolve it. I have created my own layer (say) meta-autif In the layer - I have my recipes (say) helloworld, many more may be Now I want to add these packages to the core-image-sato recipe for the image. This recipe resides in meta layer (under recipes-sato/images) I have the following recipe (say) core-image-autif.bb require core-image-sato.bb IMAGE_FEATURES += helloworld You want something like: require recipes-core/images/core-image-sato.bb -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to require image recipe from another layer?
Must be the hangover from the holidays! I typed the path as you suggested (I did replace recipes-core with recipes-sato), but I must have had a type somewhere and it did not work and gave the same error. I then tried the relative path - which I copied and pasted - instead of typing and it worked. So I assumed thats what it must have been. Now, I have the following as my recipe and it works just fine. As I said - must be the hangover from the holidays. require recipes-sato/images/core-image-sato.bb IMAGE_FEATURES += helloworld Thanks again Autif On Wed, Dec 28, 2011 at 3:31 PM, Chris Larson clar...@kergoth.com wrote: On Wed, Dec 28, 2011 at 1:22 PM, autif khan autif.ml...@gmail.com wrote: Thats right. Accounting for the relative, path, the following recipe seems to works. require ../../../meta/recipes-sato/images/core-image-sato.bb IMAGE_FEATURES += helloworld That's not what I was referring to. You don't need the full relative path. It will automatically search BBPATH if you require a relative path. if you do require recipes-sato/images/core-image-sato.bb, it will search your layers and find it. -- 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] Where is the emgd.ko module?
I built the crownbay (not crownbay-noemgd) image as outlined in the E660 development kit (link http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1) I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and followed the instructions (short version - extract, move, add meta-intel/meta-crownbay to bblayers.conf, add MACHINE=crownbay to local.conf, bitbake core-image-sato) The result was the expected set of images in tmp/deploy/images I loop mounted the core-image-sato-crownbay.ext3 and tried to find emgd.ko in the file system - I could not find it. (find output attached - notice that there is no emgd.ko) Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory called binary which contains core-image-sato-crownbay.hddimg, which contains rootfs.img, which I also loop mounted and was able to find the emgd.ko (however this image does not work with my hardware, I am not sure why). Find output for this is also included below. I very much doubt that it is included as a part of the kernel, I looked at the kernel's .config (in tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build) and could not find emgd there either. So, my questions is if I am doing something wrong? Do I need to do something to get the emgd.ko to build? I am using the latest release (6.0 Edison (released on October 17th, 2011)). Please advise. Thanks Autif autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so ./usr/lib/dri/emgd_dri.so autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so ./usr/lib/dri/emgd_dri.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/libemgdglslcompiler.so ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko ./etc/rpm-postinsts/kernel-module-emgd.sh.done autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where is the emgd.ko module?
I think that I did. Included is an excerpt that says that I need not do anything except bitbake core image sato when MACHINE=crownbay. As instructed, I followed the steps in section one (Building the meta-crownbay BSP layer) and ignored everything in section two (Special notes for building the meta-crownbay BSP layer) which includes instructions to patch a crownbay-noemgd with the Intel driver. Included below is the excerpt from the README. Is there a section that I am overlooking? Thanks Autif The meta-crownbay layer makes use of the proprietary Intel EMGD userspace drivers when building the crownbay machine (but not when building the crownbay-noemgd machine). If you got the BSP from the 'BSP Downloads' section of the Yocto website, the EMGD binaries needed to perform the build will already be present in the BSP, located in the meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8 directory, and you can ignore the rest of this section. On Tue, Dec 13, 2011 at 11:28 AM, Jim Abernathy jfaberna...@gmail.com wrote: On Tue, 2011-12-13 at 11:13 -0500, autif khan wrote: I built the crownbay (not crownbay-noemgd) image as outlined in the E660 development kit (link http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1) I used poky-edison-6.0.tar.bz2 and crownbay-edison-6.0.0.tar.bz2 and followed the instructions (short version - extract, move, add meta-intel/meta-crownbay to bblayers.conf, add MACHINE=crownbay to local.conf, bitbake core-image-sato) The result was the expected set of images in tmp/deploy/images I loop mounted the core-image-sato-crownbay.ext3 and tried to find emgd.ko in the file system - I could not find it. (find output attached - notice that there is no emgd.ko) Here is the kicker - crownbay-edison-6.0.0.tar.bz2 has a directory called binary which contains core-image-sato-crownbay.hddimg, which contains rootfs.img, which I also loop mounted and was able to find the emgd.ko (however this image does not work with my hardware, I am not sure why). Find output for this is also included below. I very much doubt that it is included as a part of the kernel, I looked at the kernel's .config (in tmp/work/crownbay-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+2247da9131ea7e46ed4766a69bb1353dba22f873-r2/linux-crownbay-standard-build) and could not find emgd there either. So, my questions is if I am doing something wrong? Do I need to do something to get the emgd.ko to build? I am using the latest release (6.0 Edison (released on October 17th, 2011)). Please advise. Check out the README file in the meta-crownbay directory. There are instructions on integrating the EMGD driver files into the build. Jim A Thanks Autif autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so ./usr/lib/dri/emgd_dri.so autif@xu:~/data/dev/yocto/emgd/tmp/deploy/images/1$ autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ sudo find . | grep emgd ./usr/lib/libemgdsrv_um.so ./usr/lib/dri/emgd_dri.so ./usr/lib/libemgdsrv_init.so.1.5.15.3226 ./usr/lib/libemgdsrv_init.so ./usr/lib/xorg/modules/drivers/emgd_drv.so ./usr/lib/libemgdPVR2D_DRIWSEGL.so.1.5.15.3226 ./usr/lib/libemgdglslcompiler.so.1.5.15.3226 ./usr/lib/libemgdsrv_um.so.1.5.15.3226 ./usr/lib/libemgdPVR2D_DRIWSEGL.so ./usr/lib/libemgdglslcompiler.so ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd ./lib/modules/3.0.4-yocto-standard+/kernel/drivers/gpu/drm/emgd/emgd.ko ./etc/rpm-postinsts/kernel-module-emgd.sh.done autif@xu:~/data/dev/yocto/poky-edison-6.0/meta-intel/meta-crownbay/binary/2$ ___ 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] Trying to cross compile Mono - glib link error
Here are some more environment variables (they all look as expected, I am not sure if they are right): autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep i586 CC=i586-poky-linux-gcc CFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIG_SITE=/opt/poky/1.1/site-config-i586-poky-linux CPPFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' GDB=i586-poky-linux-gdb PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games TARGET_PREFIX=i586-poky-linux- autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ On Sun, Nov 13, 2011 at 8:07 PM, autif khan autif.ml...@gmail.com wrote: I bitbaked core-image-sato-sdk It did not produce a tar.gz of the file system I improvised and (-o loop) mounted the core-image-sato-sdk-atom-pc.ext3 at /home/autif/data/dev/projects/yocto/sysroot autif@hp8440w:~/data/dev/projects/yocto/sysroot$ ls bin dev home lost+found mnt sbin tmp var boot etc lib media proc sys usr I changed the environment file as follows (notice how sysroot is updated for all variables): export PATH=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH export PKG_CONFIG_SYSROOT_DIR=/home/autif/data/dev/projects/yocto/sysroot export PKG_CONFIG_PATH=/home/autif/data/dev/projects/yocto/sysroot/usr/lib/pkgconfig export CONFIG_SITE=/opt/poky/1.1/site-config-i586-poky-linux export CC=i586-poky-linux-gcc export CXX=i586-poky-linux-g++ export GDB=i586-poky-linux-gdb export TARGET_PREFIX=i586-poky-linux- export CONFIGURE_FLAGS=--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot export CFLAGS= -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot export CXXFLAGS= -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot export LDFLAGS= --sysroot=/home/autif/data/dev/projects/yocto/sysroot export CPPFLAGS= -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot export OECORE_NATIVE_SYSROOT=/opt/poky/1.1/sysroots/x86_64-pokysdk-linux export OECORE_TARGET_SYSROOT=/home/autif/data/dev/projects/yocto/sysroot export OECORE_ACLOCAL_OPTS=-I /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/share/aclocal export OECORE_DISTRO_VERSION=1.1 export OECORE_SDK_VERSION=1.1 And I am still getting the same error. LD test-glib libtool: link: warning: library `/opt/poky/1.1/sysroots/i586-poky-linux/usr/lib/libgmodule-2.0.la' was moved. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' make[4]: *** [test-glib] Error 1 make[4]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib/test' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6' make: *** [all] Error 2 Command exited with non-zero status 2 7.05user 1.36system 0:12.62elapsed 66%CPU (0avgtext+0avgdata 60832maxresident)k 0inputs+37504outputs (0major+1185664minor)pagefaults 0swaps autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep FLAGS CFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/home/autif/data/dev/projects/yocto/sysroot' CPPFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' LDFLAGS=' --sysroot=/home/autif/data/dev/projects/yocto/sysroot' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CXX CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/home/autif/data/dev/projects/yocto/sysroot' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CC CC=i586-poky-linux-gcc SLAVE NONE ACCEPT' -- $cur )); COMPREPLY=($( compgen -W 'ACCEPT DROP LOG ULOG REJECT \ COMPREPLY=($( compgen -W 'ACCEPT DROP LOG ULOG REJECT \ COMPREPLY=($( compgen
[yocto] Trying to cross compile Mono - glib link error
I followed the instructions and installed the ADT from the 1.1 tarball as outlined in documentation. And tested a few simple GTK apps. Everything worked well. After that I am trying to cross compile mono and I am getting the following error: LD test-glib libtool: link: warning: library `/opt/poky/1.1/sysroots/i586-poky-linux/usr/lib/libgmodule-2.0.la' was moved. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' make[4]: *** [test-glib] Error 1 make[4]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib/test' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6/eglib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/autif/data/dev/projects/yocto/mono-2.10.6' make: *** [all] Error 2 compiler flags seem to look fine autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep LD BUILDDIR=/home/autif/data/dev/projects/yocto/poky-edison-6.0/build LDFLAGS=' --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' OLDPWD=/home/autif/data/dev/projects/yocto autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CPP CPPFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep CXX CXX=i586-poky-linux-g++ CXXFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' autif@hp8440w:~/data/dev/projects/yocto/mono-2.10.6$ set | grep FLAGS CFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CONFIGURE_FLAGS='--target=i586-poky-linux --host=i586-poky-linux --build=x86_64-linux --with-libtool-sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CPPFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' CXXFLAGS=' -m32 -march=i586 --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' LDFLAGS=' --sysroot=/opt/poky/1.1/sysroots/i586-poky-linux' Please advise. Thanks! Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
