Re: [yocto] [poky] Is this a bug of binutils

[Laurentiu Palcu]

Hi Li Zhijian,

On Thu, Sep 26, 2013 at 11:57:22AM +0800, Li Zhijian wrote:
> Hi，Laurentiu
> 
> I think it could be something wrong with binutils(2.23.1 or later)
> there is different behavior at 
> binutils-2.23.1/ld/ldfile.c（ldfile_open_file_search) from binutils-2.22
> 
> If both --sysroot directory and -L directory include libc.so , ld don't work
> In my case， there are double 
> libc.so(/yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-poky-linux/usr/lib/libc.so
>  and tmp/sysroots/qemux86-64/usr/lib/libc.so)
> 
> ld will link tmp/sysroots/qemux86-64/usr/lib/libc.so（ld always searchs -L 
> directory at first)
> then link /lib/libc.so.6 specified at tmp/sysroots/qemux86-64/usr/lib/libc.so 
> instead of
> append sysroot directory path before /lib/libc.so.6
> 
> here is a sample method reproduce it
> 
> lizj@suika x86-64-yocto-1.3]$ source 
> toolchain-1.3-tcmode-default/environment-setup-x86_64-poky-linux
> [lizj@suika x86-64-yocto-1.3]$ echo $CC
> x86_64-poky-linux-gcc -m64 
> --sysroot=/yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-poky-linux
> [lizj@suika x86-64-yocto-1.3]$ $LD --version
> GNU ld (GNU Binutils) 2.23.1.20121113
> [lizj@suika x86-64-yocto-1.3]$ mkdir -p fake_rootfs/usr/lib
> [lizj@suika x86-64-yocto-1.3]$ cp 
> /yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-poky-linux/usr/lib/libc.so
>  fake_rootfs/usr/lib/
This libc.so is actually a linker script with the following contents:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED 
(/lib/ld-linux-x86-64.so.2 ) )

So, the /lib/libc.so.6 and /usr/lib/libc_nonshared.a will be searched until no
undefined references are created. So, it looks like this linker script
overrides the --sysroot behavior. To be honest (even though I'm not an expert in
binutils), I think this is right behavior. I don't know why this works with the
previous binutils...

Thanks,
Laurentiu

> [lizj@suika x86-64-yocto-1.3]$ ls fake_rootfs/usr/lib/
> libc.so
> [lizj@suika x86-64-yocto-1.3]$ $CC -o test test.c -L ./fake_rootfs/usr/lib/
> test.c: In function 'main':
> test.c:3:9: warning: incompatible implicit declaration of built-in function 
> 'printf' [enabled by default]
> /yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld:
>  skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
> /yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld:
>  cannot find /lib/libc.so.6
> /yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld:
>  skipping incompatible /usr/lib/libc_nonshared.a when searching for 
> /usr/lib/libc_nonshared.a
> /yocto/fnst/lizj/build_yocto/x86-64-yocto-1.3/toolchain-1.3-tcmode-default/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld:
>  cannot find /usr/lib/libc_nonshared.a
> collect2: error: ld returned 1 exit status
> -
> 
> It seems that ld don‘t  really reasonable to do like that，which binutils-2.22 
> can handle correctly
> Does poky mind this behavior
> 
> 
> 以上
> 
> -- 
> Best regards.
> Li Zhijian
> 
> 
> 
> at 2013-9-20 19:00, Laurentiu Palcu wrote:
> >Hi,
> >
> >On Fri, Sep 20, 2013 at 06:25:19PM +0800, Li Zhijian wrote:
> >>>III） compile a simple C program
> >>># cat test.c
> >>>int main ()
> >>>{
> >>>printf("hello world\n");
> >>>return 0;
> >>>}
> >>># source 
> >>>toolchain-1.3-tcmode-default/environment-setup-x86_64-poky-linux
> >>># $CC -o test test.c -L tmp/sysroots/qemux86-64/usr/lib/ -lm
> >OK, it looks like something strange happens in your setup.
> >
> >To debug it, let's add '-Wl,--verbose' at the end of your command and you
> >should be able to see where the linker is looking for libraries. Also,
> >the linker script will be printed.
> >
> >You should see it try your directory first
> >tmp/sysroots/qemux86-64/usr/lib/, and then fall through the default ones
> >with the sysroot prefix added and, at the end, the system ones:
> >/lib:/usr/lib.
> >
> >Thanks,
> >Laurentiu
> >
> >
> 
> 
> 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Gstreamer mfw_isink

[Diego Gonzalez]

Hello,

I'm working with gstreamer using fsl-image-gui  and I tried  the next tutorial 
(Multi-Overlay) https://community.freescale.com/docs/DOC-93788  . However when 
I try to use mfw_isink,  gstreamer tells me :

WARNING: erroneous pipeline: no element "mfw_isink"

So if I inspect (gst-inspect | grep "isink"), you'll see this element is not 
installed:

alsa:  alsasink: Audio sink (ALSA)
soup:  souphttpclientsink: HTTP client sink
xvimagesink:  xvimagesink: Video sink
playback:  playsink: Player Sink
gio:  giosink: GIO sink
gio:  giostreamsink: GIO stream sink
autodetect:  autovideosink: Auto video sink
autodetect:  autoaudiosink: Auto audio sink
v4lsink.imx:  mfw_v4lsink: v4l2 video sink
coreelements:  fakesink: Fake Sink
coreelements:  fdsink: Filedescriptor Sink
coreelements:  filesink: File Sink
tcp:  tcpclientsink: TCP client sink
tcp:  tcpserversink: TCP server sink
tcp:  multifdsink: Multi filedescriptor sink
fbdevsink:  fbdevsink: fbdev video sink

How can I add it ?  

Regards,

Diego González González

diego.gonza...@horus.es___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] problem with perl and locale support in SDK

[Hans Beckérus]

Hi. We get following problem when trying to execute any perl programs
in the SDK environment.
This is an example of running 'perl -v'

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_MESSAGES = "C",
LC_COLLATE = "C",
LC_TIME = "C",
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

This is perl 5, version 14, subversion 3 (v5.14.3) built for x86_64-linux

>which perl
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/perl

Running this from inside the Yocto sysroot does not render the same problem.
>/home/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl -v

This is perl 5, version 14, subversion 3 (v5.14.3) built for
x86_64-linux-thread-multi

Why is perl built differently for native and nativesdk? Is this
something that we can control?

Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to combine BBCLASSEXTEND and variable export

[Paul Eggleton]

Hi Hans,

On Wednesday 25 September 2013 17:39:04 Hans Beckérus wrote:
> Hi. I have a recipe that use BBCLASSEXTEND to extend native. For the
> normal/base version I wish to set/export an environment variable to be
> picked up by configure.
> But I do not wish this variable to be set by the native package. How
> would I accomplish that? It was ok before when I had a package-native
> recipe but since that is obsolete in favor for BBCLASSEXTEND I wish to
> remove it. I think I covered all the other caveats like DEPEND and
> PACKAGE/FILES. But this one is not as straight forward, or is it?

If I'm understanding the requirements correctly think you could do something 
like:

do_configure_prepend_class_target() {
export VARIABLE=value
}

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem with perl and locale support in SDK

[Hans Beckérus]

On Thu, Sep 26, 2013 at 10:37 AM, Hans Beckérus  wrote:
> Hi. We get following problem when trying to execute any perl programs
> in the SDK environment.
> This is an example of running 'perl -v'
>
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LC_MESSAGES = "C",
> LC_COLLATE = "C",
> LC_TIME = "C",
> LANG = "en_US"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
>
> This is perl 5, version 14, subversion 3 (v5.14.3) built for x86_64-linux
>
>>which perl
> /opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/perl
>
> Running this from inside the Yocto sysroot does not render the same problem.
>>/home/poky/build/tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl -v
>
> This is perl 5, version 14, subversion 3 (v5.14.3) built for
> x86_64-linux-thread-multi
>
> Why is perl built differently for native and nativesdk? Is this
> something that we can control?
>
Ok, things are getting a bit more clear now. But still there are some
things that do not add up.
The perl base recipe BBCLASSEXTEND nativesdk. But there is an explicit
recipe for perl-native.
That explains why the result is so different. The base recipe includes
a patch for Debian systems to squelch the locale warning messages, but
only if DPKG_RUNNING_VERSION is set in the environment (and it is not
set by the SDK initialization script). But why was it not possible to
use the same build of perl both for native and nativesdk? The native
version of perl does not include this patch and it does not output any
locale warning either! So obviously perl is ok on the current running
host, but was not good enough for the SDK? What am I missing here?

> Thanks.
> Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to combine BBCLASSEXTEND and variable export

[Hans Beckérus]

On Thu, Sep 26, 2013 at 12:13 PM, Paul Eggleton
 wrote:
> Hi Hans,
>
> On Wednesday 25 September 2013 17:39:04 Hans Beckérus wrote:
>> Hi. I have a recipe that use BBCLASSEXTEND to extend native. For the
>> normal/base version I wish to set/export an environment variable to be
>> picked up by configure.
>> But I do not wish this variable to be set by the native package. How
>> would I accomplish that? It was ok before when I had a package-native
>> recipe but since that is obsolete in favor for BBCLASSEXTEND I wish to
>> remove it. I think I covered all the other caveats like DEPEND and
>> PACKAGE/FILES. But this one is not as straight forward, or is it?
>
> If I'm understanding the requirements correctly think you could do something
> like:
>
> do_configure_prepend_class_target() {
> export VARIABLE=value
> }
>
Yes, I believe I tried that, but then the export does not persist over
do_configure(), does it?
It is only alive during the scope of do_configure_prepend() or?

> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] BBCLASSEXTEND nativesdk vs native weirdness?

[Hans Beckérus]

For a recipe that extends to native and nativesdk, why are these not
resolved in the same way when trying to build the packages?
To build native you do 'bitbake foo-native' but for nativesdk that
does not work, but instead 'bitbake nativesdk-foo' is possible?
This is really confusing! Does this mix up also apply to DEPEND etc.
In that case this must be really error prone? Or is it some old legacy
that
can not be changed until all existing nativesdk-.bb files have
been replaced, either with -nativesdk.bb or using BBCLASSEXTENDs?

Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to combine BBCLASSEXTEND and variable export

[Paul Eggleton]

On Thursday 26 September 2013 12:38:13 Hans Beckérus wrote:
> On Thu, Sep 26, 2013 at 12:13 PM, Paul Eggleton
>  wrote:
> > On Wednesday 25 September 2013 17:39:04 Hans Beckérus wrote:
> >> Hi. I have a recipe that use BBCLASSEXTEND to extend native. For the
> >> normal/base version I wish to set/export an environment variable to be
> >> picked up by configure.
> >> But I do not wish this variable to be set by the native package. How
> >> would I accomplish that? It was ok before when I had a package-native
> >> recipe but since that is obsolete in favor for BBCLASSEXTEND I wish to
> >> remove it. I think I covered all the other caveats like DEPEND and
> >> PACKAGE/FILES. But this one is not as straight forward, or is it?
> > 
> > If I'm understanding the requirements correctly think you could do
> > something like:
> > 
> > do_configure_prepend_class_target() {
> > 
> > export VARIABLE=value
> > 
> > }
> 
> Yes, I believe I tried that, but then the export does not persist over
> do_configure(), does it?
> It is only alive during the scope of do_configure_prepend() or?

The _prepend is just prepended to the function before running it, so it will 
be applied for the entire function. If you have a look at 
temp/run.do_configure.* in the workdir for the recipe, you'll be able to verify 
this.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Antwort: Re: Antwort: Re: Is it possible to add machine specific changes in a separate custom layer?

[Felix01 Fischer]

Hi Paul
Another follow up Question :-)

Paul Eggleton  schrieb am 25.09.2013 
14:33:04:

> Von: Paul Eggleton 
> An: Felix01 Fischer , 
> Kopie: yocto@yoctoproject.org
> Datum: 25.09.2013 14:33
> Betreff: Re: Antwort: Re: [yocto] Is it possible to add machine 
> specific changes in a separate custom layer?
> 
> Hi Felix,
> 
> On Wednesday 25 September 2013 10:19:41 Felix01 Fischer wrote:
> > One Question: I want to add changes to a %MACHINE.conf via my layer
> > (to be specific: I want to add "APPEND += "video=LVDS-1:d" to
> > meta-intel/meta-chiefriver/conf/machine/chiefriver.conf)
> > Is this also possible via a separate layer? Once again, I didn't find 
out
> > via the documentation. ATM I have to modify the chiefriver.conf 
directly
> 
> Really the way to do this kind of thing is to have your own custom 
distro 
> config. If you're doing anything beyond the basics you should 
> probably have one 
> anyway. Generally this kind of thing is usually about how you are using 
the 
> machine as opposed to supporting the machine itself, so it's more ofa 
distro 
> policy type situation.

Is it possible to refer to a whole BSP?
For example, like the cronwbay.conf requires tune-atom.inc.
I would like to require the whole meta-crownbay BSP layer.
I tried this the naive way with a custom "/conf/machine/$MACHINE.conf and 
added
"require x/meta-crownbay/conf/machine/crownbay.conf" but that didn't 
worked.


> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

Regards,
Felix___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Antwort: Re: Antwort: Re: Is it possible to add machine specific changes in a separate custom layer?

[Paul Eggleton]

Hi Felix,

On Thursday 26 September 2013 12:59:24 Felix01 Fischer wrote:
> Is it possible to refer to a whole BSP?
> For example, like the cronwbay.conf requires tune-atom.inc.
> I would like to require the whole meta-crownbay BSP layer.
> I tried this the naive way with a custom "/conf/machine/$MACHINE.conf and
> added
> "require x/meta-crownbay/conf/machine/crownbay.conf" but that didn't
> worked.

This should work though:

require conf/machine/crownbay.conf

(Since "require" searches for files using BBPATH which will point to the base 
of each layer).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Question about DEPENDS and eg. DEPENDS_class-native

[Hans Beckérus]

Hi. Browsing through the existing recipes really did not answer this
since I have no clue what was the initial intent.
So my quick question is if a .inc file has a DEPENDS = "foo" and a
recipe that includes it has DEPENDS_class-native = "fee", will the
resulting depend be merged from the two or will DEPENDS_class-native
completely override DEPENDS? If it overrides, is the correct way to
merge them to do DEPENDS_append_class-native = "fee"?

Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] Add util-linux-agetty to core-image-selinux IMAGE_INSTALL.

[Joe MacDonald]

All opposed?  If the motion is carried, I'll merge it both into master
and what will soon become master-next.

-J.

[[yocto] [meta-selinux] Add util-linux-agetty to core-image-selinux 
IMAGE_INSTALL.] On 13.09.26 (Thu 04:58) Philip Tricca wrote:

> Currently logins to core-image-selinux images through a getty (serial)
> fail. This is caused by the use of the busybox getty. SELinux depends
> on executable files and their labels to transition between types.
> The symlink to busybox is not sufficient to cause the getty processes
> to transition to the right SELinux context. Using a getty binary
> like the one provided by util-linux fixes this.
> 
> Signed-off-by: Philip Tricca 
> ---
>  recipes-security/images/core-image-selinux.bb |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/recipes-security/images/core-image-selinux.bb 
> b/recipes-security/images/core-image-selinux.bb
> index 0109933..1ec7b08 100644
> --- a/recipes-security/images/core-image-selinux.bb
> +++ b/recipes-security/images/core-image-selinux.bb
> @@ -6,6 +6,7 @@ LICENSE = "MIT"
>  
>  IMAGE_INSTALL = "\
>   ${CORE_IMAGE_BASE_INSTALL} \
> + util-linux-agetty \
>   packagegroup-core-basic \
>   packagegroup-core-selinux \
>  "   
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to combine BBCLASSEXTEND and variable export

[Hans Beckérus]

On Thu, Sep 26, 2013 at 12:48 PM, Paul Eggleton
 wrote:
> On Thursday 26 September 2013 12:38:13 Hans Beckérus wrote:
>> On Thu, Sep 26, 2013 at 12:13 PM, Paul Eggleton
>>  wrote:
>> > On Wednesday 25 September 2013 17:39:04 Hans Beckérus wrote:
>> >> Hi. I have a recipe that use BBCLASSEXTEND to extend native. For the
>> >> normal/base version I wish to set/export an environment variable to be
>> >> picked up by configure.
>> >> But I do not wish this variable to be set by the native package. How
>> >> would I accomplish that? It was ok before when I had a package-native
>> >> recipe but since that is obsolete in favor for BBCLASSEXTEND I wish to
>> >> remove it. I think I covered all the other caveats like DEPEND and
>> >> PACKAGE/FILES. But this one is not as straight forward, or is it?
>> >
>> > If I'm understanding the requirements correctly think you could do
>> > something like:
>> >
>> > do_configure_prepend_class_target() {
>> >
>> > export VARIABLE=value
>> >
>> > }
>>
>> Yes, I believe I tried that, but then the export does not persist over
>> do_configure(), does it?
>> It is only alive during the scope of do_configure_prepend() or?
>
> The _prepend is just prepended to the function before running it, so it will
> be applied for the entire function. If you have a look at
> temp/run.do_configure.* in the workdir for the recipe, you'll be able to 
> verify
> this.
>
Ah, yes. Of course it works like that. What was I thinking :)
Thanks for the help Paul. I must have done some mistake before which
made it go wrong.

> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about DEPENDS and eg. DEPENDS_class-native

[Hans Beckerus]

On 2013-09-26 2:41, Hans Beckérus wrote:
> Hi. Browsing through the existing recipes really did not answer this
> since I have no clue what was the initial intent.
> So my quick question is if a .inc file has a DEPENDS = "foo" and a
> recipe that includes it has DEPENDS_class-native = "fee", will the
> resulting depend be merged from the two or will DEPENDS_class-native
> completely override DEPENDS? If it overrides, is the correct way to
> merge them to do DEPENDS_append_class-native = "fee"?
Ok, this one I managed to figure out by doing some trial and error.
What I have learned from that exercise is that if you wish to extend DEPENDS 
specifically you need to do DEPENDS_append_class-native = " "
Doing DEPENDS_class-native = " will override DEPENDS completely for native 
builds. Please correct me if I am wrong.

> Thanks.
> Hans

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

[yocto] Best way to reuse install scripts across multiple recipes?

[Brad Litterell]

I'm finding that I use a pattern like this in a number of recipes to install 
all the files that exist in a particular folder, generally scripts or data 
files:

# copy scripts
pushd ${S}/files/bin
# note that failure in the exec is not always captured here, so this needs 
to be enhanced
# to catch that kind of build failure.
find . -type f -exec install -m 0644 {} ${D}/bin/{} \;
popd

As the comment exists, I need to expand this to a real loop with error handing, 
so I'm wondering if (a) there already exists a similar call that I can reuse in 
yocto (similar to oe_libinstall), or (b) whether I should add it to 
utils.bbclass, or a private recipe.  Would it be useful to submit back to the 
project?  Or am I just going about a common task the wrong way?

I'm thinking of adding a function like this:

oe_folderinstall   

Thanks,
Brad
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Bitbake Commander New Project Bug

[Jate Sujjavanich]

Creating a Yocto Bitbake Commander project using an existing poky directory is 
a little buggy. I usually do this to avoid downloading poky from the Internet.

The plugin wizard implies that you can use a poky directory in your workspace 
with its clone from yocto repository option.

Attempting to use a cloned poky in workspace/poky results in the wizard 
reporting that ".../workspace/poky overlaps the location of another project: 
poky." Changing the name of the project merely results in the error "Directory 
...workspace/poky2 does not exist, please select git clone".

The workaround is to open a separate dummy workspace, and then run the wizard 
with Project Location pointing to your desired Project Location. You will then 
be able to hit Finish. Eclipse will create the .metadata and .eclipse-data 
files.

You can then switch to your desired workspace and use "Import an Existing 
Project."

Is this a bug?


-Jate S.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux] Check for the availability of 'secon' and 'setenforce' in the selinux-init.sh script.

[Philip Tricca]

This is for consistency and to aid in debugging.

Signed-off-by: Philip Tricca 
---
 recipes-security/selinux/selinux-config/selinux-init.sh |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-security/selinux/selinux-config/selinux-init.sh 
b/recipes-security/selinux/selinux-config/selinux-init.sh
index 1cdc3dd..8f3efac 100644
--- a/recipes-security/selinux/selinux-config/selinux-init.sh
+++ b/recipes-security/selinux/selinux-config/selinux-init.sh
@@ -6,8 +6,10 @@ CHCON=/usr/bin/chcon
 MATCHPATHCON=/usr/sbin/matchpathcon
 FIXFILES=/sbin/fixfiles
 RESTORECON=/sbin/restorecon
+SECON=/usr/bin/secon
+SETENFORCE=/usr/sbin/setenforce
 
-for i in ${CHCON} ${MATCHPATHCON} ${FIXFILES} ${RESTORECON} ; do
+for i in ${CHCON} ${MATCHPATHCON} ${FIXFILES} ${RESTORECON} ${SECON} 
${SETENFORCE}; do
test -x $i && continue
echo "$i is missing in the system."
echo "Please add \"selinux=0\" in the kernel command line to disable 
SELinux."
@@ -51,12 +53,12 @@ fi
 
 # If first booting, the security context type of init would be
 # "kernel_t", and the whole file system should be relabeled.
-if [ "`/usr/bin/secon -t --pid 1`" = "kernel_t" ]; then
+if [ "`${SECON} -t --pid 1`" = "kernel_t" ]; then
echo "Checking SELinux security contexts:"
check_rootfs
echo " * First booting, filesystem will be relabeled..."
test -x /etc/init.d/auditd && /etc/init.d/auditd start
-   /usr/sbin/setenforce 0
+   ${SETENFORCE} 0
${RESTORECON} -R /
${RESTORECON} /
echo " * Relabel done, rebooting the system."
-- 
1.7.10.4

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

[yocto] [meta-selinux] Resend: Install policy headers and include them in the refpolicy dev package.

[Philip Tricca]

To do this we call the 'install-headers' make target at the end of
do_install. We then add the interface 'include' directory to the
dev package leaving only the policy modules in the main policy
package. This allows projects that ship their own SELinux policy
(not in the refpolicy) to build the refpolicy headers / interface
files by using the Makefile supplied by refpolicy.

Signed-off-by: Philip Tricca 
---
 recipes-security/refpolicy/refpolicy_common.inc |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 2c8891a..0f9f83b 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -12,7 +12,8 @@ SRC_URI += "file://customizable_types \
 S = "${WORKDIR}/refpolicy"
 
 FILES_${PN} = "${sysconfdir}/selinux/${POLICY_NAME}/ \
-   ${datadir}/selinux/${POLICY_NAME}/"
+   ${datadir}/selinux/${POLICY_NAME}/*.pp"
+FILES_${PN}-dev =+ "${datadir}/selinux/${POLICY_NAME}/include/"
 
 DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
 RDEPENDS_${PN} += "policycoreutils selinux-config"
@@ -75,4 +76,7 @@ EOF
 
cat ${WORKDIR}/customizable_types >> \

${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/customizable_types
+
+   # install policy headers
+   oe_runmake install-headers DESTDIR=${D}
 }
-- 
1.7.10.4

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

[yocto] Question about automatic debug package generation

[Brad Litterell]

My recipe builds and ships an executable in /foo/bin/fooapp

FILES_${PN} += "/foo/bin/*"

WARNING: QA Issue: foo: Files/directories were installed but not shipped
  /foo/bin/.debug
  /foo/bin/.debug/fooapp

This file doesn't appear in the image, but is in the package folder:
./package/foo/bin/.debug/fooapp

It appears something is automatically creating these .debug files during the 
packaging steps, but the corresponding file isn't under packages-split.

Can someone point me to a place to learn more about how these are created and 
packaged?

Thanks,
Brad

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

Re: [yocto] Question about automatic debug package generation

[Nicolas Dechesne]

On Fri, Sep 27, 2013 at 12:00 AM, Brad Litterell  wrote:

> My recipe builds and ships an executable in /foo/bin/fooapp
>
>  FILES_${PN} += "/foo/bin/*"
>
>  WARNING: QA Issue: foo: Files/directories were installed but not shipped
>   /foo/bin/.debug
>   /foo/bin/.debug/fooapp
>
>  This file doesn't appear in the image, but is in the package folder:
>  ./package/foo/bin/.debug/fooapp
>
>  It appears something is automatically creating these .debug files during
> the packaging steps, but the corresponding file isn't under packages-split.
>
>
>  Can someone point me to a place to learn more about how these are
> created and packaged?
>

this is done in meta/classes/package.bbclass. at the beginning of that
file, you will find an overall description of what the 'packaging' steps
are, and you can see, among many things:

# d) split_and_strip_files - split the files into runtime and debug and
strip them.

#Debug files include debug info split, and associated sources that end
up in -dbg packages

you can then check the source code for the function split_and_strip_files.

Now, about 'packaging' the files, you need to look at
meta/conf/bitbake.conf and search for FILES_{PN}-dbg. this is the default
variable that specifies which files go into the -dbg package. Your issue
above is because the 'default' path for binary is /usr/bin, hence the
'default' path for debug variants is /usr/bin/.debug. But if you need
'/foo' , you can change these default in your recipe, by modifying
FILES_{PN}xxx in your .bb file.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Mono 2.10.8.1 (meta-mono) Corelib not in sync with runtime...

[Ryan Kirkpatrick]

On Fri, 20 Sep 2013, Ryan Kirkpatrick wrote:

> I am trying to get Mono 2.10 working on a core-image-basic running on 
> qemux86 machine. I am using pokay-dylan-9.0.2 on a Debian 6.0.7 system for 
> the builds and been able to build and run images without issue. Yet, when 
> I went to add the meta-mono layer from git.yoctoporject.org, I started 
> running into problems.
> 
> Corlib not in sync with this runtime: expected corlib version 96, found 100.
> Loaded from: /usr/lib/mono/2.0/mscorlib.dll
> Download a newer corlib or a newer runtime at http://www.go-mono.com/daily.

I dug into the mono build and figured out that I had a version mismatch 
between 'mono' (builds the runtime for the target) and 'mono-native' 
(builds a runtime for the build system and uses it to build the corlib). 
The key was defining both of the following in local.conf, not just the 
first line which is all I had originally.

PREFERRED_VERSION_mono = "2.10.8.1"
PREFERRED_VERSION_mono-native = "2.10.8.1"

Anyway, attached is a patch against meta-mono (from 
git://git.yoctoproject.org/meta-mono) that makes these changes:
 - Adds a comment to the README about the two configs above.
 - Reconfigures mono to be built without X support, skip as desired.
 - A few packaging tweaks, namely moving the bulky *.mdb (Mono debug 
   databases) to the -dbg package.
 - Adjustment to QA packaging checks to resolve errors encountered.
 - Moved the mono-2.10.8.1 folder in meta-mono/recipes/mono to 
   meta-mono/recipes/mono/files so the contents can be found.
 - Quick fix to mono-xsp recipe to avoid parsing error, probably not the 
   fix to make if mono-xsp was going to be built (but I am not).

Hope that helps some one, it does myself as I can now run Mono apps in my 
qemux86 target. Next challenge is to do the same with a qemuarm target 
(actual hardware comes later :)!

---
| Ryan Kirkpatrick | Boulder, CO | rkirkpat.net | twitter.com/rkirkpatnet |
---Index: meta-mono/README
===
--- meta-mono/README	(revision 4704)
+++ meta-mono/README	(working copy)
@@ -34,8 +34,17 @@
 Windows Forms applications. While mono can run w/o X, that recipe
 is not supported currently. It is unlikely to be supported.
 
+WARNING:
+If not building the latest version of Mono, make sure that
+PREFERRED_VERSION_* is defined for both mono and mono-native.
+Otherwise the runtime (built by mono recipe) and corlib (built by
+mono-native recipe) will not be in sync! That is, to build Mono
+v2.10.8.1, put this in local.conf or a distro conf:
 
+PREFERRED_VERSION_mono = "2.10.8.1"
+PREFERRED_VERSION_mono-native = "2.10.8.1"
 
+
 3) Maintainer(s) & Patch policy
 
 Autif Khan (autif.ml...@gmail.com)
Index: meta-mono/recipes-mono/mono/mono_2.10.8.1.bb
===
--- meta-mono/recipes-mono/mono/mono_2.10.8.1.bb	(revision 4704)
+++ meta-mono/recipes-mono/mono/mono_2.10.8.1.bb	(working copy)
@@ -2,11 +2,12 @@
 
 inherit autotools pkgconfig
 
-DEPENDS =+ "mono-native libgdiplus"
+DEPENDS =+ "mono-native"
 
-PR = "r0"
+PR = "r1"
 
 EXTRA_OECONF += "--disable-mcs-build mono_cv_uscore=no --with-tls=pthread --with-sigaltstack=no --with-mcs-docs=no"
+EXTRA_OECONF += "--without-x --without-moonlight --without-libgdiplus"
 
 do_configure_prepend() {
 	autoreconf -Wcross --verbose --install --force || bbnote "mono failed to autoreconf"
@@ -25,6 +26,9 @@
 FILES_${PN} += "${libdir}/libikvm-native.so"
 FILES_${PN} += "${libdir}/libMonoPosixHelper.so"
 FILES_${PN} += "${libdir}/libMonoSupportW.so"
+FILES_${PN} += "${datadir}/mono-2.0"
+FILES_${PN} += "${datadir}/libgc-mono"
+FILES_${PN}-dbg += "usr/lib/mono/*/*.mdb usr/lib/mono/*/*/*.mdb usr/lib/mono/*/*/*/*.mdb"
 
-INSANE_SKIP_${PN} = "arch dev-so debug-files"
+INSANE_SKIP_${PN} = "arch dev-so debug-files ldflags"
 
Index: meta-mono/recipes-mono/mono/files/mono-2.10.8.1/Makefile.am.diff
===
--- meta-mono/recipes-mono/mono/files/mono-2.10.8.1/Makefile.am.diff	(revision 0)
+++ meta-mono/recipes-mono/mono/files/mono-2.10.8.1/Makefile.am.diff	(revision 4765)
@@ -0,0 +1,15 @@
+--- mono-2.10.8.1.orig/Makefile.am	2012-01-25 14:24:43.564002232 -0500
 mono-2.10.8.1/Makefile.am	2012-01-25 14:25:02.036002218 -0500
+@@ -4,10 +4,10 @@
+ MOONLIGHT_SUBDIRS = $(libgc_dir) eglib/src mono
+ 
+ if CROSS_COMPILING
+-SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) data runtime scripts man samples msvc $(docs_dir)
++SUBDIRS = po $(libgc_dir) eglib mono $(ikvm_native_dir) support data runtime scripts man samples msvc $(docs_dir)
+ # Keep in sync with SUBDIRS
+ ## 'tools' is not normally built
+-DIST_SUBDIRS = po libgc eglib mono ikvm-native data runtime scripts man samples tools msvc docs
++DIST_SUBDIRS = po libgc eglib mono ikvm-n

[yocto] [meta-selinux] Add ${bindir}/sepolgen to system-config-selinux package.

[Philip Tricca]

Currently the policycoreutils package has a broken link from
${bindir}/sepolgen to ${datadir}/system-config-selinux/polgen.py.
All of the other polgen stuff is in system-config-selinux so
adding sepolgen to same package seems like the right thing to do.

Signed-off-by: Philip Tricca 
---
 recipes-security/selinux/policycoreutils.inc |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-security/selinux/policycoreutils.inc 
b/recipes-security/selinux/policycoreutils.inc
index 08b14eb..7939095 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -48,7 +48,10 @@ FILES_${PN}-python = 
"${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"
 FILES_${PN}-sandbox = "${datadir}/sandbox/*"
 FILES_${PN}-sandbox += "${bindir}/sandbox"
 FILES_${PN}-sandbox += "${sbindir}/seunshare"
-FILES_system-config-selinux = "${datadir}/system-config-selinux/*"
+FILES_system-config-selinux = " \
+${bindir}/sepolgen \
+${datadir}/system-config-selinux/* \
+"
 
 inherit pythonnative
 
-- 
1.7.10.4

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

[yocto] how to add a new bb(xerces-c)?

[曹志研]

Hello, everyone!
I try to add a new bb(xerces-c) to my image, bb is as followings:


DESCRIPTION = "Xerces-C++ is a validating XML parser written in a portable 
subset of C++."
HOMEPAGE = "http://xerces.apache.org/xerces-c/";
LICENSE = "Apache"
LIC_FILES_CHKSUM = 
"file://src/xercesc/dom/DOM.hpp;endline=22;md5=9986d741cab88a8b7bc4a19d3c1b8106 
\
file://src/xercesc/parsers/XercesDOMParser.hpp;endline=21;md5=85be7b6e587aa51e4f30c262f1cd695e
 \
file://src/xercesc/xinclude/XIncludeDOMDocumentProcessor.hpp;endline=23;md5=4236d3c0f2537b3df547a97d60f93dc0"


PR = "r1"


DEPENDS = "curl icu"


SRC_URI = 
"http://mirror.bit.edu.cn/apache//xerces/c/3/sources/xerces-c-${PV}.tar.gz";


SRC_URI[md5sum] = "6a8ec45d83c8cfb1584c5a5345cb51ae"
SRC_URI[sha256sum] = 
"a42785f71e0b91d5fd273831c87410ce60a73ccfdd207de1b805d26d44968736"


inherit autotools


S = "${WORKDIR}/xerces-c-${PV}/"


EXTRA_OECONF = "\
--enable-netaccessor-curl \
--enable-transcoder-icu \
--enable-msgloader-icu \
"


but when configure come into the error:
ERROR: This autoconf log indicates errors, it looked at host include and/or 
library paths while determining system capabilities.
Rerun configure task after fixing this. The path was 
'/home/caozhiyan/fsl-community-bsp/build-hc1200/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xerces-c/3.1.1-r1/xerces-c-3.1.1'
ERROR: Function failed: do_qa_configure
ERROR: Logfile of failure stored in: 
/home/caozhiyan/fsl-community-bsp/build-hc1200/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xerces-c/3.1.1-r1/temp/log.do_configure.19932
ERROR: Task 5 
(/home/caozhiyan/fsl-community-bsp/sources/meta-fsl-hc1200/recipes-hc1200/xerces-c/xerces-c_3.1.1.bb,
 do_configure) failed with exit code '1'


who can show me how to port the autotools-based project? Thanks.___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about automatic debug package generation

[Brad Litterell]

Thanks Nicolas!

Sent from my Windows Phone

From: Nicolas Dechesne
Sent: ‎9/‎26/‎2013 15:29
To: Brad Litterell
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Question about automatic debug package generation


On Fri, Sep 27, 2013 at 12:00 AM, Brad Litterell 
mailto:b...@evidence.com>> wrote:
My recipe builds and ships an executable in /foo/bin/fooapp

FILES_${PN} += "/foo/bin/*"

WARNING: QA Issue: foo: Files/directories were installed but not shipped
  /foo/bin/.debug
  /foo/bin/.debug/fooapp

This file doesn't appear in the image, but is in the package folder:
./package/foo/bin/.debug/fooapp

It appears something is automatically creating these .debug files during the 
packaging steps, but the corresponding file isn't under packages-split.

Can someone point me to a place to learn more about how these are created and 
packaged?

this is done in meta/classes/package.bbclass. at the beginning of that file, 
you will find an overall description of what the 'packaging' steps are, and you 
can see, among many things:

# d) split_and_strip_files - split the files into runtime and debug and strip 
them.
#Debug files include debug info split, and associated sources that end up 
in -dbg packages
you can then check the source code for the function split_and_strip_files.

Now, about 'packaging' the files, you need to look at meta/conf/bitbake.conf 
and search for FILES_{PN}-dbg. this is the default variable that specifies 
which files go into the -dbg package. Your issue above is because the 'default' 
path for binary is /usr/bin, hence the 'default' path for debug variants is 
/usr/bin/.debug. But if you need '/foo' , you can change these default in your 
recipe, by modifying FILES_{PN}xxx in your .bb file.




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

Re: [yocto] how to add a new bb(xerces-c)?

[Gaurang Shastri]

Hi,

You can look at
http://git.yoctoproject.org/cgit/cgit.cgi/experimental/meta-m2/plain/packages/xerces-c/xerces-c_2.8.0.bb

//Gaurang Shastri



On Fri, Sep 27, 2013 at 11:05 AM, 曹志研  wrote:

> Hello, everyone!
> I try to add a new bb(xerces-c) to my image, bb is as followings:
>
> DESCRIPTION = "Xerces-C++ is a validating XML parser written in a portable
> subset of C++."
> HOMEPAGE = "http://xerces.apache.org/xerces-c/";
> LICENSE = "Apache"
> LIC_FILES_CHKSUM =
> "file://src/xercesc/dom/DOM.hpp;endline=22;md5=9986d741cab88a8b7bc4a19d3c1b8106
> \
> file://src/xercesc/parsers/XercesDOMParser.hpp;endline=21;md5=85be7b6e587aa51e4f30c262f1cd695e
> \
>
> file://src/xercesc/xinclude/XIncludeDOMDocumentProcessor.hpp;endline=23;md5=4236d3c0f2537b3df547a97d60f93dc0"
>
> PR = "r1"
>
> DEPENDS = "curl icu"
>
> SRC_URI = 
> "http://mirror.bit.edu.cn/apache//xerces/c/3/sources/xerces-c-${PV}.tar.gz";
>
> SRC_URI[md5sum] = "6a8ec45d83c8cfb1584c5a5345cb51ae"
> SRC_URI[sha256sum] =
> "a42785f71e0b91d5fd273831c87410ce60a73ccfdd207de1b805d26d44968736"
>
> inherit autotools
>
> S = "${WORKDIR}/xerces-c-${PV}/"
>
> EXTRA_OECONF = "\
> --enable-netaccessor-curl \
> --enable-transcoder-icu \
> --enable-msgloader-icu \
> "
>
> but when configure come into the error:
> ERROR: This autoconf log indicates errors, it looked at host include
> and/or library paths while determining system capabilities.
> Rerun configure task after fixing this. The path was
> '/home/caozhiyan/fsl-community-bsp/build-hc1200/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xerces-c/3.1.1-r1/xerces-c-3.1.1'
> ERROR: Function failed: do_qa_configure
> ERROR: Logfile of failure stored in:
> /home/caozhiyan/fsl-community-bsp/build-hc1200/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xerces-c/3.1.1-r1/temp/log.do_configure.19932
> ERROR: Task 5
> (/home/caozhiyan/fsl-community-bsp/sources/meta-fsl-hc1200/recipes-hc1200/xerces-c/
> xerces-c_3.1.1.bb, do_configure) failed with exit code '1'
>
> who can show me how to port the autotools-based project? 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

Re: [yocto] Question about automatic debug package generation

[Hans Beckérus]

On Fri, Sep 27, 2013 at 8:11 AM, Brad Litterell  wrote:
> Thanks Nicolas!
>
> Sent from my Windows Phone
> 
> From: Nicolas Dechesne
> Sent: 9/26/2013 15:29
> To: Brad Litterell
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Question about automatic debug package generation
>
>
> On Fri, Sep 27, 2013 at 12:00 AM, Brad Litterell  wrote:
>>
>> My recipe builds and ships an executable in /foo/bin/fooapp
>>
>> FILES_${PN} += "/foo/bin/*"
>>
>> WARNING: QA Issue: foo: Files/directories were installed but not shipped
>>   /foo/bin/.debug
>>   /foo/bin/.debug/fooapp
>>
>> This file doesn't appear in the image, but is in the package folder:
>> ./package/foo/bin/.debug/fooapp
>>
>> It appears something is automatically creating these .debug files during
>> the packaging steps, but the corresponding file isn't under packages-split.
>>
>> Can someone point me to a place to learn more about how these are created
>> and packaged?
>
>
> this is done in meta/classes/package.bbclass. at the beginning of that file,
> you will find an overall description of what the 'packaging' steps are, and
> you can see, among many things:
>
> # d) split_and_strip_files - split the files into runtime and debug and
> strip them.
> #Debug files include debug info split, and associated sources that end
> up in -dbg packages
> you can then check the source code for the function split_and_strip_files.
>
> Now, about 'packaging' the files, you need to look at meta/conf/bitbake.conf
> and search for FILES_{PN}-dbg. this is the default variable that specifies
> which files go into the -dbg package. Your issue above is because the
> 'default' path for binary is /usr/bin, hence the 'default' path for debug
> variants is /usr/bin/.debug. But if you need '/foo' , you can change these
> default in your recipe, by modifying FILES_{PN}xxx in your .bb file.
>
>
Actually, I have a related question. If you choose to install -dbg
variants, you will get a .debug folder copied to the target.
That .debug folder can then be pointed out by debuggers etc. to get
the symbol information, right?
How can the package handler know what files to strip? Does it use some
simple file magic match? I have a case now for which I made a set of
working recipes for Erlang. Erlang .beam files also contain symbols
that can be stripped, but not the conventional way. I guess I need to
add something to the do_package phase to compensate for that, but will
it interfere with what is done in package.bbclass?

Thanks.
Hans

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