Date   

Re: ERROR: QA Issue: No GNU_HASH in the elf binary

Saxena, Rahul <rahul.saxena@...>
 

Looks like the order of packages (as shown in bitbake.conf) in PACKAGES variable is different in 1.3_M3 compared to Denzel.

In 1.3_M3, ${PN} package is last (that is comes after ${PN}-dev package) ..so that probably explains the issue.
I will explicitly change it and try-out.

Chris, you were right bitbake.conf was the place to look at :)

Rahul

-----Original Message-----
From: Saxena, Rahul
Sent: Tuesday, August 21, 2012 12:25 PM
To: 'Chris Larson'
Cc: Khem Raj; yocto@yoctoproject.org
Subject: RE: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

oe-core/meta/conf/bitbake.conf specifies the default package settings.
However the problem I seem to be seeing is that my recipe is not able to override the default.

However let me know if I should still be looking at that file..

Rahul

-----Original Message-----
From: kergoth@gmail.com [mailto:kergoth@gmail.com] On Behalf Of Chris Larson
Sent: Tuesday, August 21, 2012 12:07 PM
To: Saxena, Rahul
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul <rahul.saxena@intel.com> wrote:
You are right, these are regular files and not symlinks and are ending
up in usr/lib in packagename-dev package However I want them to be in the regular package.

I do have the following statement in my recipe:

FILES_${PN} += "${libdir}/lib*.so"

and nothing in my recipe has statements such as FILES_${PN)-dev = ...

Read oe-core/meta/conf/bitbake.conf.

--
Christopher Larson


Re: ERROR: QA Issue: No GNU_HASH in the elf binary

Saxena, Rahul <rahul.saxena@...>
 

oe-core/meta/conf/bitbake.conf specifies the default package settings.
However the problem I seem to be seeing is that my recipe is not able to override the default.

However let me know if I should still be looking at that file..

Rahul

-----Original Message-----
From: kergoth@gmail.com [mailto:kergoth@gmail.com] On Behalf Of Chris Larson
Sent: Tuesday, August 21, 2012 12:07 PM
To: Saxena, Rahul
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul <rahul.saxena@intel.com> wrote:
You are right, these are regular files and not symlinks and are ending
up in usr/lib in packagename-dev package However I want them to be in the regular package.

I do have the following statement in my recipe:

FILES_${PN} += "${libdir}/lib*.so"

and nothing in my recipe has statements such as FILES_${PN)-dev = ...

Read oe-core/meta/conf/bitbake.conf.

--
Christopher Larson


Re: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

Brian Lloyd <blloyd@...>
 

FYI: new user stuck having to implement a bps found the description below about the extra demarcation between groups and partitions helpful. Now if only I knew which branches were partitions and which where groups...


Brian A Lloyd

On Aug 21, 2012, at 12:14 PM, Darren Hart <darren.hart@intel.com> wrote:

On 08/20/2012 09:13 PM, Bruce Ashfield wrote:

+Kernel types (ktypes) are the highest level policy containers and represent
+a significant set of kernel functionality that has been grouped (and named)
+or partitioned.
What are you trying to convey with "partitioned" vs. "grouped" ? The
"or" indicates a functional difference, but it isn't clear what that is
from this reading.
partitioned means that they are really being kept apart since they won't
work together (think BFS vs CFS, or grsec vs another security patch).
Grouped
just means that you have 15 or 20 things that you want to collectively
call a "kernel type" and validate that they work together in a particular
configuration. But there's no fundamental incompatibility between these
features and others in the system.

It's a hard vs soft partitioning.

Would the expansion that I have above help ?
Hrm, nah. Let's leave it and address it if someone else raises a
concern. I might be alone here.

+ - behaviour. A kernel type defines a default behaviour, which is often a
behaviour: a kernel type ...
You left my Canadian behaviour .. my spell checker thanks you! Fixed.
With a UK architect it seemed presumptuous to do otherwise ;-)

+named category. These typically are included by kernel types, and are not
+meant to implement a defined functionality or be included multiple times.
+
+These often contain bug fixes, backports or other small changes to the kernel
+tree, and do not typically contain any kernel configuration fragments. patches
typically? How can a patch contain a config change?
That just means that a directory called 'patches' vs 'features' wouldn't
contain associated config fragments to enable that functionality. But since
the system is flexible, there's no reason they can't, so I went with
"typically" :) I can clarify.
Yeah... I think we need to kill config vs feature vs patches and merge
them together into a single term. Having the three seems to add more
confusion than information.

What do you see as the value for maintaining the 3 concepts separately?

+Config groups are collections of configuration options that when included
+enable a specific behaviour or functionality. Configuration groups do not
+contain patches, and can be included multiple times by any other feature or
+kernel type. The impact of configuration groups is additive, and order
+matters, since the last included config group can override the behaviour of
+previous includes.
Is this the same thing as "config fragment"? If so, we should pick one
and be consistent. If not, how do they differ?
I was more thinking about the "cfg" subdir and the .scc file that includes
a .cfg when I wrote this. The foo.cfg is the config fragment, the named
group is the .scc file + the .cfg.

I'm not sure it is worth splitting the hair here. I can just go with
configuration fragment. How does that sound ?
You're right, the config .scc file is not a config fragment, the .cfg
files are. So a config group includes one or more config fragments. Got it.


+Note: Depending on the architecture of the meta data, configuration groups
+can be complete, or partitioned. Complete config groups contain all the
^ comma should be removed

+options required to enable functionality, partitioned configurations rely on
+multiple includes to build up a set of non overlapping options to enable
non-overlapping

+functionality. Complete groups are simpler to include, but make it more
+difficult to remove or disable an option (since it can appear multiple
+times),
If a config fragment includes another one - isn't the end result the same?
which part ? The appear multiple times ? Yes, you can end up with thing
via fragments that include others, but not if you've partitioned them
all.

complete.scc
include complete.cfg

complete.cfg
CONFIG_A=y
CONFIG_B=y

partitioned.scc
include partitioned_a.cfg
include partitioned_b.cfg

partitioned_a.cfg
CONFIG_A=y

partitioned_b.cfg
CONFIG_B=y

This is how I understood your description. Assuming I have this right,
there is no difference between including compelte.scc or
partitioned.scc. Each will pull in all the same CONFIG* options and
modify/overwrite/etc any existing settings in exactly the same way. This
is what I meant by "same end result".

I guess what you're saying is the partitioned approach is more modular
and allows for changing a specific option in one place (CONFIG_A in
partitioned_a.cfg which will roll up into partitioned.scc) rather than
having several scc's similar to complete.scc which all need to be
modidfied to change CONFIG_A.

That could probably be made clearer.

+supports and is the typical entry point of a build system to the
+configuration data of the meta branch.
For whatever reason, that reads as very abstract and is rather difficult
to parse. I understand it... but _I_ needed to read it several times,
and I know the system fairly well...
.. I'll try something easier on the head, I was trying to stay out
of .scc file syntax, which is probably why it reads hard. Maybe this ?

The machine is the top-level description of a board, and the hardware
that it supports. A machine/BSP .scc file is found by a build system
I would stick with machine or BSP, but not confuse the issue by using
both. In the case of the linux-yocto meta data, the term BSP is more
discoverable as it maps to the directory name.

to start the processing of a particular machine and kernel type
combination. From the machine description, all the source code changes
(patches, features) and configuration changes that are used to
configure and build the kernel are located.
It's still a bit round about. How about:

The BSP .scc files combine the policy from the kernel type with the
hardware requirements of the machine into a single place. This file
describes all the source code changes from patches and features and the
configuration changes that are used to configure and build the kernel.


Changes made and pushed to the yocto-kernel-cache, we can continue to
iterate,
but this review was very helpful!
Great. Thanks for doing the write-up Bruce.


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: ERROR: QA Issue: No GNU_HASH in the elf binary

Chris Larson <clarson@...>
 

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul <rahul.saxena@intel.com> wrote:
You are right, these are regular files and not symlinks and are ending up in usr/lib in packagename-dev package
However I want them to be in the regular package.

I do have the following statement in my recipe:

FILES_${PN} += "${libdir}/lib*.so"

and nothing in my recipe has statements such as FILES_${PN)-dev = ...

Read oe-core/meta/conf/bitbake.conf.
--
Christopher Larson


Re: ERROR: QA Issue: No GNU_HASH in the elf binary

Saxena, Rahul <rahul.saxena@...>
 

You are right, these are regular files and not symlinks and are ending up in usr/lib in packagename-dev package
However I want them to be in the regular package.

I do have the following statement in my recipe:

FILES_${PN} += "${libdir}/lib*.so"

and nothing in my recipe has statements such as FILES_${PN)-dev = ...


So it seems that the build is making a assumption these are symlinks and
and should necessarily go into -dev package ignoring my above statement in the above. How do I fix this ?
The denzel branch of poky does not have this behavior, I checked that it is not putting any .so files in -dev package.

Thanks
Rahul

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, August 21, 2012 11:09 AM
To: Saxena, Rahul
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 11:03 AM, Saxena, Rahul <rahul.saxena@intel.com> wrote:
cdv-pvr-driver-dev/usr/lib/libOpenVGU.so
this seems to be a proper file and not a symlink so firstly you have .so in -dev packages if you fix that it will work secondly if you intentionally want those .so in -dev package then add

INSANE_SKIP_${PN}-dev = "ldflags"

as well.


Re: Toolchain rework, call for testing

Martin Jansa
 

On Tue, Aug 21, 2012 at 10:15:47AM -0700, Khem Raj wrote:
On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa <martin.jansa@gmail.com> wrote:

Maybe it's because
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not OEBasicHash here).
yes seems so. I have stopped using OEBasic long ago, you should stop
using it too.
I'm using OEBasicHash on one jenkins setup, but that one is still
building changes from 2 days ago.. (building 24/7.. )

But feel free to send a PR bump patchlet.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


Re: How does bitbake work

Tim Bird <tim.bird@...>
 

On 08/21/2012 01:11 AM, Liu wrote:
Hi all,
In order to learn to use poky,I am wondering how bitbake works with so many
recipes. When I bitbake <target>, I want to know how bitbake collect the
providers of <target> . Then bitbake will prepare the runqueue tasks to build
the <target>.So I need to know which tasks to assign to build the <target>.And
bitbake run these tasks in what order.In other words according to the
characteristics of what to decided to implement which task first and then next.
I am very eager to know the answers.
I'm not an expert, but here's some information that I believe is correct.
(If someone else knows better, please correct this...)

bitbake reads the entire set of recipe files that are specified by
the local configuration, and parses them all into a global task namespace.
This includes all the class files and include files as well. These
are specified by the BBFILES and BBLAYERS variables in the conf/bblayers.conf
file. Within the layers directories, the <layer-dir>/conf/layer.conf
file is used to indicate the set of .bb files to parse for that layer.

Note that this global parse of the entire set of recipe files is
quite different from 'make', which usually operated on a single Makefile.
(This is also why bitbake startup is a little slow).

Information in the meta-data (the DEPENDS and PROVIDES lines) determine
package ordering. Where packages are independent of each other, the
build order is dependent (I believe) on file parse order. In this case,
processing is not required to be in any particular order (and, in fact,
can be parallelized). You can have bitbake produce the dependency graph
of the packages for your build by using the -g option. This produces output in
'dot' syntax (suitable for processing using some graphviz visualizer).

The list of tasks to perform within a package appears to come
from the common class meta-data
(see meta/classes/utility-tasks.bbclass, for example) and the
meta-data for the individual package These are added by
the 'addtask' keyword. You can see a list of tasks for an
individual package with: bitbake <pkg> -c listtasks

I have started to put together an overview introduction of Yocto at:
http://elinux.org/Yocto_Project_Introduction

I haven't gotten much completed yet, but I do discuss bitbake there
a bit. Hopefully what I've got so far will be helpful.
-- Tim

P.S. someone correct me if I'm wrong.

Thanks ,
------ Yu Liu
Following is the some output of bitbake busybox and in this example I want
to know why first do the task of (quilt-native_0.51.bb, do_fetch) :
Parsing recipes...done.
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34
skipped, 0 masked, 0 errors.
OE Build Configuration:
BB_VERSION = "1.15.2"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "qemuarm"
DISTRO = "poky"
DISTRO_VERSION = "1.2.1"
TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
TARGET_FPU = "soft"
meta
meta-yocto = "<unknown>:<unknown>"
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++
(external-csl-toolchain, gcc-cross)
NOTE: consider defining a PREFERRED_PROVIDER entry to match
virtual/arm-none-linux-gnueabi-g++
NOTE: multiple providers are available for runtime linux-libc-headers-dev
(linux-libc-headers, linux-libc-headers-yocto, linux-libc-headers-yocto-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match linux-libc-headers-dev
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 706 (ID: 18,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
do_fetch)
NOTE: Running task 2 of 706 (ID: 228,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_20111111.bb,
do_fetch)
NOTE: Running task 3 of 706 (ID: 189,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
do_fetch)
NOTE: Running task 4 of 706 (ID: 515,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb,
do_fetch)
NOTE: package gnu-config-native-20111111-r1: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_fetch: Started
NOTE: package gnu-config-native-20111111-r1: task do_fetch: Succeeded
NOTE: Running task 5 of 706 (ID: 224,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_20111111.bb,
do_unpack)
NOTE: package gnu-config-native-20111111-r1: task do_unpack: Started
NOTE: package gnu-config-native-20111111-r1: task do_unpack: Succeeded
NOTE: Running task 6 of 706 (ID: 202,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Succeeded
NOTE: Running task 7 of 706 (ID: 511,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb,
do_unpack)
NOTE: package m4-native-1.4.16-r2: task do_unpack: Started
NOTE: package m4-native-1.4.16-r2: task do_unpack: Succeeded
NOTE: Running task 8 of 706 (ID: 215,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb,
do_fetch)
NOTE: package autoconf-native-2.68-r7: task do_fetch: Succeeded
NOTE: Running task 9 of 706 (ID: 185,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Succeeded
NOTE: Running task 10 of 706 (ID: 254,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb,
do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Succeeded
NOTE: Running task 11 of 706 (ID: 198,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Succeeded
NOTE: Running task 12 of 706 (ID: 450,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb,
do_fetch)
NOTE: package pkgconfig-native-0.25-r3: task do_fetch: Started
WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.6.tar.bz2
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Succeeded
NOTE: Running task 13 of 706 (ID: 250,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb,
do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_unpack: Started
NOTE: package pkgconfig-native-0.25-r3: task do_fetch: Succeeded
NOTE: Running task 14 of 706 (ID: 446,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb,
do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_unpack: Succeeded
NOTE: Running task 15 of 706 (ID: 241,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/gettext/gettext-minimal-native_0.18.1.1.bb,
do_fetch)
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_fetch: Started
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_fetch: Succeeded
NOTE: Running task 16 of 706 (ID: 237,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/gettext/gettext-minimal-native_0.18.1.1.bb,
do_unpack)
NOTE: package pkgconfig-native-0.25-r3: task do_unpack: Started
NOTE: package pkgconfig-native-0.25-r3: task do_unpack: Succeeded
NOTE: Running task 17 of 706 (ID: 463,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/ncurses/ncurses_5.9.bb,
do_fetch)
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_unpack: Started
NOTE: package gettext-minimal-native-0.18.1.1-r3: task do_unpack: Succeeded
NOTE: Running task 18 of 706 (ID: 528,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/ocf-linux_20100325.bb,
do_fetch)
NOTE: package ncurses-native-5.9-r9.1: task do_fetch: Started
NOTE: package ocf-linux-native-20100325-r3.0: task do_fetch: Started
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Succeeded
NOTE: Running task 19 of 706 (ID: 211,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb,
do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_unpack: Started
NOTE: package libtool-native-2.4.2-r2.0: task do_unpack: Succeeded
NOTE: Running task 20 of 706 (ID: 280,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb,
do_fetch)
NOTE: package openssl-native-1.0.0i-r0.2: task do_fetch: Started
NOTE: package ncurses-native-5.9-r9.1: task do_fetch: Succeeded
NOTE: Running task 21 of 706 (ID: 459,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/ncurses/ncurses_5.9.bb,
do_unpack)
NOTE: package ncurses-native-5.9-r9.1: task do_unpack: Started
NOTE: package ncurses-native-5.9-r9.1: task do_unpack: Succeeded
NOTE: Running task 22 of 706 (ID: 176,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-support/sqlite/sqlite3_3.7.10.bb,
do_fetch)
NOTE: package sqlite3-native-3.7.10-r2: task do_fetch: Started
WARNING: Failed to fetch URL
http://download.savannah.gnu.org/releases/quilt/quilt-0.51.tar.gz
NOTE: package openssl-native-1.0.0i-r0.2: task do_fetch: Succeeded
NOTE: Running task 23 of 706 (ID: 276,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-connectivity/openssl/openssl_1.0.0i.bb,
do_unpack)
NOTE: package openssl-native-1.0.0i-r0.2: task do_unpack: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Succeeded
NOTE: Running task 24 of 706 (ID: 14,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
do_unpack)
NOTE: package openssl-native-1.0.0i-r0.2: task do_unpack: Succeeded
NOTE: Running task 25 of 706 (ID: 541,
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-extended/pigz/pigz_2.2.4.bb,
do_fetch)
NOTE: package quilt-native-0.51-r1: task do_unpack: Started
NOTE: package quilt-native-0.51-r1: task do_unpack: Succeeded
NOTE: Running task 26 of 706 (ID: 15,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
do_patch)
NOTE: package pigz-native-2.2.4-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_patch: Started
NOTE: package quilt-native-0.51-r1: task do_patch: Succeeded
NOTE: Running task 27 of 706 (ID: 20,
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
do_configure)
NOTE: package quilt-native-0.51-r1: task do_configure: Started

--
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: ERROR: QA Issue: No GNU_HASH in the elf binary

Khem Raj
 

On Tue, Aug 21, 2012 at 11:03 AM, Saxena, Rahul <rahul.saxena@intel.com> wrote:
cdv-pvr-driver-dev/usr/lib/libOpenVGU.so
this seems to be a proper file and not a symlink so firstly you have
.so in -dev packages
if you fix that it will work secondly if you intentionally want those
.so in -dev package
then add

INSANE_SKIP_${PN}-dev = "ldflags"

as well.


ERROR: QA Issue: No GNU_HASH in the elf binary

Saxena, Rahul <rahul.saxena@...>
 

Hi,

 

I am using  poky/1.3_M3 branch and I get a bunch of “ERROR: QA Issue: No GNU_HASH in the elf binary:”

 

My recipe is for installing binary files only.

I have the following statement in my recipe:

 

INSANE_SKIP_${PN} = “ldflags”

 

But I still get the errors ..any suggestions ?

 

WARNING: File '/usr/lib/libEGL.so.1' from cdv-pvr-driver was already stripped, this will prevent future debugging!

WARNING: File '/usr/lib/libGLESv2.so.2' from cdv-pvr-driver was already stripped, this will prevent future debugging!

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_LINUXFBWSEGL.so'

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_DRIWSEGL.so'

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libPVROGL_MESA.so'

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libOpenVGU.so'

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_BLITWSEGL.so'

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_FLIPWSEGL.so'

 

 

Thanks

Rahul


Re: yocto-bsp create

Tom Zanussi <tom.zanussi@...>
 

On Fri, 2012-08-17 at 20:56 +0100, Chris Tapp wrote:
On 17 Aug 2012, at 20:47, Bruce Ashfield wrote:

On 12-08-17 03:40 PM, Chris Tapp wrote:

On 17 Aug 2012, at 20:33, Bruce Ashfield wrote:

On 12-08-17 03:32 PM, Chris Tapp wrote:
On 17 Aug 2012, at 15:59, Bruce Ashfield wrote:

On 12-08-17 06:47 AM, Chris Tapp wrote:

On 17 Aug 2012, at 00:48, Bruce Ashfield wrote:

ech. That means that the tree was somehow dirty and branches couldn't
be switched/checked out.

If you have a copy of your BSP layer, I can try a build here and shed
some light on what exactly went wrong.

Thanks Bruce. Meta layer attached.
Fixed here. This was completely generated from the tools ? If so, the
branching information was wrong.

KBRANCH_LX800 = "standard/default/LX800"
YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/LX800"

The "base" is always inferred and only exists because of the
way that git manages refs on disk. So the branch that you
want to build is what I have above, and the tools will
automatically make that branch point off the default/base
branch.

Let me know if that did come from the tools and I'll follow
up to the list.
I'm 99.99% sure it did, but it runs ok after making the changes you give above, deleting tmp/ and rebuilding.

I've not g0t any real changes in yet, so I'll go try again and see what I get. It's just possible I didn't do a complete rebuild (i.e. nuke tmp/) which may have caused a problem last time round.
ok. cool. no rush. I was just going to do a final update on the mailing
list to not leave it hanging, and if there's a bug in the scripts, we
can let Tom know .. so he can fix it!

I've just recreated the BSP. I selected option 4 for the kernel branch (standard/default/base), which gives:

KBRANCH_LX800 = "standard/default/base/LX800"
YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/base/LX800"
ok. Worth firing off a bug report to Tom Zaunussi. .. that
won't work .. ever.
Just bringing this back on-list.

I'll get something added to the tracker.
Just back from vacation and getting to this...

Yeah, this is a known bug and was fixed by the yocto-bsp patchsets I
sent out just before I left. See the last entry in the bug below for
links to the branches that fixed it and a few other issues:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=2693

I see that the denzil branch has been updated with the changes, but have
yet to hit master.

Tom

Chris Tapp

opensource@keylevel.com
www.keylevel.com



_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [OE-core] RFC: OE-Core task rework

Philip Balister
 

On 08/21/2012 01:49 AM, Paul Eggleton wrote:
On Monday 20 August 2012 15:45:07 Mark Hatle wrote:
...


Yup, there is a logical grouping for the lsb specific tasks, as for others.
The naming needs to be made clear as to why it's there, and what it
represents. Same with the summary and descriptions -- they should list the
functionality provided by this group of components.
The main concern with LSB is that we have something called task-basic, which
seems to be intended for LSB but does not state as much, and I know at least
one person has tried to use it and then been a little puzzled as to why rpm
has been pulled in when ipk packaging has been selected. Just naming some of
these tasks more appropriately would help avoid such situations. In the
specific case of task-basic there may be a case for creating a similar but not
LSB-focused task that pulls in real shell utilities in preference to the light
versions provided by busybox.
I was seriously stumped by the presence of rpm in what I felt should have been a very basic image. If a task/group is targeted at lsb, it needs to have lsb plastered all over the name so the rest of us can avoid it :)

Philip


4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
converts some IMAGE_FEATURES into the addition of tasks to be installed
(see classes/core-image.bbclass). At the very least we should probably
rename this if we rename tasks to package groups, and there's a question
as to how IMAGE_FEATURES scales - should every task be represented in
there or only a select list? Would we be better off not trying to bring
any tasks in via IMAGE_FEATURES at all and mostly leave that to control
post-processing (e.g. package-management, debug-tweaks, etc.)?
I'd certainly prefer that images were limited to selecting software from
task (group) recipes only, and not providing their own. An image should be
able to change the selection based on an "image feature" or similar
configuration, but the underlying tasks/groups, recipes, etc should all be
'generic' to a given distribution configuration.
The first part seems reasonable to me; but I'm still short of an answer as to
what to do with the existing IMAGE_FEATURES code as mentioned above. At the
moment aside from the special features such as debug-tweaks, these are just a
thin layer on top of task recipes which doesn't add very much at all other
than extra maintenance.

I think if you go through the images today, a lot of that stuff is either
old, or could be simplified by creating appropriate tasks/groups.
OK, that's a good point. I have another task on my list to clean up our image
recipes and that would be a good segue into that.

Cheers,
Paul


Re: Toolchain rework, call for testing

Khem Raj
 

On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa <martin.jansa@gmail.com> wrote:

Maybe it's because
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not OEBasicHash here).
yes seems so. I have stopped using OEBasic long ago, you should stop
using it too.
But feel free to send a PR bump patchlet.


Re: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

Darren Hart <darren.hart@...>
 

On 08/20/2012 09:13 PM, Bruce Ashfield wrote:

+Kernel types (ktypes) are the highest level policy containers and represent
+a significant set of kernel functionality that has been grouped (and named)
+or partitioned.
What are you trying to convey with "partitioned" vs. "grouped" ? The
"or" indicates a functional difference, but it isn't clear what that is
from this reading.
partitioned means that they are really being kept apart since they won't
work together (think BFS vs CFS, or grsec vs another security patch).
Grouped
just means that you have 15 or 20 things that you want to collectively
call a "kernel type" and validate that they work together in a particular
configuration. But there's no fundamental incompatibility between these
features and others in the system.

It's a hard vs soft partitioning.

Would the expansion that I have above help ?
Hrm, nah. Let's leave it and address it if someone else raises a
concern. I might be alone here.

+ - behaviour. A kernel type defines a default behaviour, which is often a
behaviour: a kernel type ...
You left my Canadian behaviour .. my spell checker thanks you! Fixed.
With a UK architect it seemed presumptuous to do otherwise ;-)

+named category. These typically are included by kernel types, and are not
+meant to implement a defined functionality or be included multiple times.
+
+These often contain bug fixes, backports or other small changes to the kernel
+tree, and do not typically contain any kernel configuration fragments. patches
typically? How can a patch contain a config change?
That just means that a directory called 'patches' vs 'features' wouldn't
contain associated config fragments to enable that functionality. But since
the system is flexible, there's no reason they can't, so I went with
"typically" :) I can clarify.
Yeah... I think we need to kill config vs feature vs patches and merge
them together into a single term. Having the three seems to add more
confusion than information.

What do you see as the value for maintaining the 3 concepts separately?

+Config groups are collections of configuration options that when included
+enable a specific behaviour or functionality. Configuration groups do not
+contain patches, and can be included multiple times by any other feature or
+kernel type. The impact of configuration groups is additive, and order
+matters, since the last included config group can override the behaviour of
+previous includes.
Is this the same thing as "config fragment"? If so, we should pick one
and be consistent. If not, how do they differ?
I was more thinking about the "cfg" subdir and the .scc file that includes
a .cfg when I wrote this. The foo.cfg is the config fragment, the named
group is the .scc file + the .cfg.

I'm not sure it is worth splitting the hair here. I can just go with
configuration fragment. How does that sound ?
You're right, the config .scc file is not a config fragment, the .cfg
files are. So a config group includes one or more config fragments. Got it.


+Note: Depending on the architecture of the meta data, configuration groups
+can be complete, or partitioned. Complete config groups contain all the
^ comma should be removed

+options required to enable functionality, partitioned configurations rely on
+multiple includes to build up a set of non overlapping options to enable
non-overlapping

+functionality. Complete groups are simpler to include, but make it more
+difficult to remove or disable an option (since it can appear multiple
+times),
If a config fragment includes another one - isn't the end result the same?
which part ? The appear multiple times ? Yes, you can end up with thing
via fragments that include others, but not if you've partitioned them
all.

complete.scc
include complete.cfg

complete.cfg
CONFIG_A=y
CONFIG_B=y

partitioned.scc
include partitioned_a.cfg
include partitioned_b.cfg

partitioned_a.cfg
CONFIG_A=y

partitioned_b.cfg
CONFIG_B=y

This is how I understood your description. Assuming I have this right,
there is no difference between including compelte.scc or
partitioned.scc. Each will pull in all the same CONFIG* options and
modify/overwrite/etc any existing settings in exactly the same way. This
is what I meant by "same end result".

I guess what you're saying is the partitioned approach is more modular
and allows for changing a specific option in one place (CONFIG_A in
partitioned_a.cfg which will roll up into partitioned.scc) rather than
having several scc's similar to complete.scc which all need to be
modidfied to change CONFIG_A.

That could probably be made clearer.

+supports and is the typical entry point of a build system to the
+configuration data of the meta branch.
For whatever reason, that reads as very abstract and is rather difficult
to parse. I understand it... but _I_ needed to read it several times,
and I know the system fairly well...
.. I'll try something easier on the head, I was trying to stay out
of .scc file syntax, which is probably why it reads hard. Maybe this ?

The machine is the top-level description of a board, and the hardware
that it supports. A machine/BSP .scc file is found by a build system
I would stick with machine or BSP, but not confuse the issue by using
both. In the case of the linux-yocto meta data, the term BSP is more
discoverable as it maps to the directory name.

to start the processing of a particular machine and kernel type
combination. From the machine description, all the source code changes
(patches, features) and configuration changes that are used to
configure and build the kernel are located.
It's still a bit round about. How about:

The BSP .scc files combine the policy from the kernel type with the
hardware requirements of the machine into a single place. This file
describes all the source code changes from patches and features and the
configuration changes that are used to configure and build the kernel.


Changes made and pushed to the yocto-kernel-cache, we can continue to
iterate,
but this review was very helpful!
Great. Thanks for doing the write-up Bruce.


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: adding packages in my Yocto

Paul Eggleton
 

On Tuesday 21 August 2012 12:51:41 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Paul Eggleton wrote:
On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.
if there's no objection, i added how to add multiple packages as
well, just below that.
Looks good to me, thanks.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: adding packages in my Yocto

Robert P. J. Day
 

On Tue, 21 Aug 2012, Paul Eggleton wrote:

On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.
if there's no objection, i added how to add multiple packages as
well, just below that.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: adding packages in my Yocto

Paul Eggleton
 

On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to

conf/local.conf:
IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.
Fixed.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: ia32-base.inc: Drop glibc --with-tls option, its now the only option for glibc

Darren Hart <darren.hart@...>
 

On 08/21/2012 12:13 AM, Richard Purdie wrote:
This option is unused by (e)glibc since 2011 and is the default. It has been
shown to interact badly with the configure option in atom-pc from meta-yocto
causing a rebuild of the whole system despite the only change being an
assignment with += vs =. The easiest fix is simply to drop it.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Seems clearly correct.

Acked-by: Darren Hart <dvhart@linux.intel.com>




diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc
index 99ac352..17ff714 100644
--- a/conf/machine/include/ia32-base.inc
+++ b/conf/machine/include/ia32-base.inc
@@ -21,7 +21,6 @@ SERIAL_CONSOLE ?= "115200 ttyS0"
# glibc-related variables
#
GLIBC_ADDONS ?= "nptl"
-GLIBC_EXTRA_OECONF += "--with-tls"

#
# kernel-related variables


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Documenting the mailing lists.

Darren Hart <dvhart@...>
 

On 08/20/2012 04:19 PM, Paul Eggleton wrote:
On Monday 20 August 2012 15:50:37 Darren Hart wrote:
On 08/20/2012 03:43 PM, Jeff Osier-Mixon wrote:
On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart <dvhart@linux.intel.com>
wrote:
On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
The mailing lists and website stuff is generally my responsibility,
but please fix anything you like. :) Be aware that the new website is
No intent to take over anything, I've just had to answer the "what goes
where" question a few too many times these last couple of weeks and felt
I should do something about it :-)
Oh, I'm not joking - please fix anything you want! or Scott or I can
do it. Thanks for getting the ball rolling. I'll catch up on this
thread.

I made sure you were on CC so you could help guide this.

under construction, so I am loathe to change much on the old website
at this point. For the new one, it may be possible to dynamically
grab the description from mailman.
We'll still need descriptions of the non-yocto-project lists, so that
may not be particularly helpful.
The only YP-related, non-YP lists I currently track are
openembedded-core and bitbake-devel. Both are OE lists, and I have
recently volunteered to help admin, so can make sure they have valid
Descriptions. If there are other lists we should track, please let me
know and I'll add them to the pile.
The only additional one that we reference in the manual is:

* http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
- Discussion mailing list about OpenEmbedded.

I'm not sure we need reference it at all though, perhaps oe-core is
sufficient.
FYI, the reason I added oe-devel is because it's the list that is used to
discuss/submit patches for almost all OE community layers other than OE-Core
and the ones that are hosted on yoctoproject.org.
Fair enough.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


Re: adding packages in my Yocto

David Stewart
 

Good advice. A quick check of openembedded-core shows that gst-ffmpeg appears to be one of the packages available. Yes, definitely check the hob.

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Jeff Osier-Mixon
Sent: Tuesday, August 21, 2012 9:01 AM
To: aaryak gautam
Cc: Yocto Project
Subject: Re: [yocto] adding packages in my Yocto

Hi - please take a look at the FAQ here:
https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

IMAGE_INSTALL_append += " package"

Use your own package name in place of package. Note the leading space
before the package name.
For more information, read this chapter in the Yocto Project
Development Manual
(http://www.yoctoproject.org/docs/current/dev-manual/dev-
manual.html#usingpoky-extend-addpkg).

I also highly recommend trying out the Hob interface, as it makes the
whole system easier to understand. I like to make changes in the Hob
and then examine those changes in the resulting configuration files to
better understand the system at work.

Hope this helps!

On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam <aaryak.gautam@gmail.com>
wrote:
Hello

I am a hobbyist and quite new to both Linux and Yocto.
I had already compiled my Yocto kernel for I.MX23 successfully.
But I want to add few packages.
Like if i want to have ffmpeg in my yocto,how should I add it?
I have gone through the documentation,but could not understand.

can you help me out?
I am using Bitbake core-image-minimal , not sato.


Thank You.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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


Re: adding packages in my Yocto

Robert P. J. Day
 

On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:

Hi - please take a look at the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

IMAGE_INSTALL_append += " package"
grrrrrr ... ^ "="

the "+=" is redundant.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================