[yocto] "(-)"??

[Takashi Matsuzawa]

Hello.
I am seeing some of the recipes contains lines like below.

> COMPATIBLE_MACHINE = "(-)"

Sorry being novice, but what is the intended effect of this line?
I can see submit comments that this is for blacklisting but I am not sure how 
it works.  It simply means a '-' letter?


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

Re: [yocto] local file update vs rebuild

[Takashi Matsuzawa]

Helli, thank you for your confirmation.

From: Burton, Ross <ross.bur...@intel.com>
Sent: Wednesday, August 2, 2017 8:47:00 PM
To: Takashi Matsuzawa
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] local file update vs rebuild

If you modify a recipe then anything that depends on it will be rebuilt.  So 
changing a file referenced in SRC_URI in a recipe will cause the image to 
rebuild if you build the image.

Ross

On 2 August 2017 at 12:03, Takashi Matsuzawa 
<tmatsuz...@xevo.com<mailto:tmatsuz...@xevo.com>> wrote:

Hello.

Thank you for your comment.


I want to double check.


 = image name

 = recipe within 


Then, I am not sure if doing below will rebuild  from scratch.


$ bitbake  -c cleansstate

$ bitbake 


Especially, I am doing things like below within my .


SRC_URI += "file://src/*;subdir=local"


I want to be sure that, if I make modification to the local files (referred to 
as file://... path within SRC_URI variable of  recipe), the changes are 
reflected to the final image.

(Not explicitly specifying -c cleansstate to ).


From: Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
Sent: Tuesday, August 1, 2017 3:42 AM
To: Takashi Matsuzawa; yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] local file update vs rebuild



On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> Hello.
> I am uncertain about do_clean behavior with local files.
>
>
> Say, I have local files referred by my recipe, and I have made changes to the 
> files referred.
> (Note, there is no change in my .bb<http://.bb> file itself.)
>
>
>> SRC_URI += "file://src/*;subdir=local"
>
>
> What makes those changed files reflected to the build?
> Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
>
>
> According to the document
>
>
>> do_clean
>> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, 
>> do_install, and do_package).
>> if no changes have been made and the recipe is rebuilt after cleaning, 
>> output files are simply restored from the sstate cache.
>
>
> I want to avoid doing do_cleanall often, and I would like to tell bitbake 
> that my recipe needs rebuild at the same time not rebuilding others.
> But at the same time I want to avoid building my single explicity.
> I just want to build the image name as target.

I think ccleansstate should be good.

>
>


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


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

Re: [yocto] local file update vs rebuild

[Takashi Matsuzawa]

Hello.

Thank you for your comment.


I want to double check.


 = image name

 = recipe within 


Then, I am not sure if doing below will rebuild  from scratch.


$ bitbake  -c cleansstate

$ bitbake 


Especially, I am doing things like below within my .


SRC_URI += "file://src/*;subdir=local"


I want to be sure that, if I make modification to the local files (referred to 
as file://... path within SRC_URI variable of  recipe), the changes are 
reflected to the final image.

(Not explicitly specifying -c cleansstate to ).


From: Khem Raj <raj.k...@gmail.com>
Sent: Tuesday, August 1, 2017 3:42 AM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] local file update vs rebuild



On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> Hello.
> I am uncertain about do_clean behavior with local files.
>
>
> Say, I have local files referred by my recipe, and I have made changes to the 
> files referred.
> (Note, there is no change in my .bb file itself.)
>
>
>> SRC_URI += "file://src/*;subdir=local"
>
>
> What makes those changed files reflected to the build?
> Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
>
>
> According to the document
>
>
>> do_clean
>> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, 
>> do_install, and do_package).
>> if no changes have been made and the recipe is rebuilt after cleaning, 
>> output files are simply restored from the sstate cache.
>
>
> I want to avoid doing do_cleanall often, and I would like to tell bitbake 
> that my recipe needs rebuild at the same time not rebuilding others.
> But at the same time I want to avoid building my single explicity.
> I just want to build the image name as target.

I think ccleansstate should be good.

>
>

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

[yocto] local file update vs rebuild

[Takashi Matsuzawa]

Hello.
I am uncertain about do_clean behavior with local files.


Say, I have local files referred by my recipe, and I have made changes to the 
files referred.
(Note, there is no change in my .bb file itself.)


>SRC_URI += "file://src/*;subdir=local"


What makes those changed files reflected to the build?
Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?


According to the document


> do_clean
> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, do_install, 
> and do_package).
> if no changes have been made and the recipe is rebuilt after cleaning, output 
> files are simply restored from the sstate cache. 


I want to avoid doing do_cleanall often, and I would like to tell bitbake that 
my recipe needs rebuild at the same time not rebuilding others.
But at the same time I want to avoid building my single explicity.
I just want to build the image name as target.


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

[yocto] build for terasic de10 nano kit?

[Takashi Matsuzawa]

Hello.
I recently purchased Terasic DE10-Nano Kit board, and I wonder how I can build 
Linux image for it.
(Though it comes with binary SD card.)

I can see below, and I tried meta-de10-nano/REDME.md steps (priecisely it is 
not yocto?), but I met errors during bitbake.

https://01.org/meta-de10-nano
https://github.com/01org/meta-de10-nano

And I can see below.
I would love to see the steps that I can try. Or any comminity mailing list 
that I can check such tips?

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


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

Re: [yocto] bilding webkit/qtwebengine?

[Takashi Matsuzawa]

Hello.

>yes you can do that via a local.conf entry like
>
>PARALLEL_MAKE_pn-qtwebengine  = "-j 8"

Thank you this seems to work very well.

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

[yocto] bilding webkit/qtwebengine?

[Takashi Matsuzawa]

Hello.
I am seeing issue with threads/parallel make.  I wonder if anyone has 
experience/suggestion.

My question: is if it is possible that I set parallel make numbers to lower 
only for a few recipes that are known to resource hog?

I am building webkig/chrome related recipes (e.g. qtwebengine or alike) as part 
of my image build.  I have been setting parallel thread / make parameters 
relatively high in the past, say 20-30.
So far it worked well and it make me finish my build faster.

Then, I added these components to my image, then the build crashes (jenkins 
killed with lack of memory).
I imagine these components have complex build system within it, so it is more 
resource hog compared to the other “ordinal” components.

I imagine that by reducing the parallel make configuration numbers to lower, 
the build will not break for webkits, but at the same time, it will be slower 
to the other parts of the build.

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

Re: [yocto] dynamic-layers?

[Takashi Matsuzawa]

Hello.


So, this is the case I have to be careful about the order of conf files listed 
in BBLAYERS list?

i.e. if I have dynamic-layers line in my layer X and expansion need to take 
care of layer A, B, C, then, A, B, C needs to be apper before X within BBLAYERS 
list.


From: Takashi Matsuzawa
Sent: Thursday, May 25, 2017 3:26 PM
To: yocto@yoctoproject.org
Cc: Nicolas Dechesne
Subject: Re: [yocto] dynamic-layers?


Hello.


I further did some debugging and BBFOLE_COLLECTION when used in the following 
'for' expansion contains only subset of what is avilable finally in 
BBFILE_COLLECTION (as appears in '-e' log).


>BBFILES += "${@'  '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' 
>% layer \
>   for layer in BBFILE_COLLECTIONS.split())}"

I am confused if this is a normal behavior.

____
From: Takashi Matsuzawa
Sent: Thursday, May 25, 2017 10:03 AM
To: Nicolas Dechesne
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?


Hello.

>e.g. if you have meta-qt5 in BBLAYERS in /conf/bblayers.conf, then the 
>recipes from "dynamic-layers/qt5-layer" are used as well.

Thanks now I can see how it is expected to work.
My issue here now is that some dynamyc-layers/ not being added to 
BBFILES list.

I tried '-e' switch with my build tree and here is what I can see.
I think this is caused by BBFILE_COLLECTIONS evaluation timing? - but I am 
still looking into to find the cause.

1) .conf files read

I think these are the conf files recognized by the build sytem.
I cansee meta-qt5 there.

#
# INCLUDE HISTORY:
#
# /home/xxx/build-root/build/conf/bblayers.conf
# /home/xxx/build-root/meta-freescale/conf/layer.conf
# /home/xxx/build-root/meta-freescale-3rdparty/conf/layer.conf
# /home/xxx/build-root/meta-freescale-distro/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-netboot/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-smack/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-framework/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-app-framework/conf/layer.conf
# /home/xxx/build-root/meta-qt5/conf/layer.conf
...

2) BBFILE_COLLECTIONS

And I can see 'qt5-layer' is being added to BBFILE_COLLECTIONS, so it 
'qt5-layer' folder in every dynamic-layers should be picked into BBFILE list.

BBFILE_COLLECTIONS=" freescale-layer fsl-arm-extra fsl-demos
meta-netboot security-smack security-framework app-framework qt5-layer
agl-demo openembedded-layer multimedia-layer efl-layer
networking-layer meta-python ivi-common agl agl-distro aglbsp core
yocto"

3) BBFILES

But I cannot find it in BBFILES list.
Only the first 4 layers (freescale-layer/fsl-arm-extra/fsl-demos/meta-netboot) 
in BBFILE_COLLECTIONS are used in wildecard parameter.

BBFILES="/home/xxx/build-root/meta-freescale/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale/recipes-*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bbappend
...



From: Nicolas Dechesne <nicolas.deche...@linaro.org>
Sent: Wednesday, May 24, 2017 11:19 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?

On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa <tmatsuz...@xevo.com> wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf

>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> 

Re: [yocto] dynamic-layers?

[Takashi Matsuzawa]

Hello.

>e.g. if you have meta-qt5 in BBLAYERS in /conf/bblayers.conf, then the 
>recipes from "dynamic-layers/qt5-layer" are used as well.

Thanks now I can see how it is expected to work.
My issue here now is that some dynamyc-layers/ not being added to 
BBFILES list.

I tried '-e' switch with my build tree and here is what I can see.
I think this is caused by BBFILE_COLLECTIONS evaluation timing? - but I am 
still looking into to find the cause.

1) .conf files read

I think these are the conf files recognized by the build sytem.
I cansee meta-qt5 there.

#
# INCLUDE HISTORY:
#
# /home/xxx/build-root/build/conf/bblayers.conf
# /home/xxx/build-root/meta-freescale/conf/layer.conf
# /home/xxx/build-root/meta-freescale-3rdparty/conf/layer.conf
# /home/xxx/build-root/meta-freescale-distro/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-netboot/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-smack/conf/layer.conf
# 
/home/xxx/build-root/meta-intel-iot-security/meta-security-framework/conf/layer.conf
# /home/xxx/build-root/meta-agl/meta-app-framework/conf/layer.conf
# /home/xxx/build-root/meta-qt5/conf/layer.conf
...

2) BBFILE_COLLECTIONS

And I can see 'qt5-layer' is being added to BBFILE_COLLECTIONS, so it 
'qt5-layer' folder in every dynamic-layers should be picked into BBFILE list.

BBFILE_COLLECTIONS=" freescale-layer fsl-arm-extra fsl-demos
meta-netboot security-smack security-framework app-framework qt5-layer
agl-demo openembedded-layer multimedia-layer efl-layer
networking-layer meta-python ivi-common agl agl-distro aglbsp core
yocto"

3) BBFILES

But I cannot find it in BBFILES list.
Only the first 4 layers (freescale-layer/fsl-arm-extra/fsl-demos/meta-netboot) 
in BBFILE_COLLECTIONS are used in wildecard parameter.

BBFILES="/home/xxx/build-root/meta-freescale/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale/recipes-*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bbappend
/home/xxx/build-root/meta-freescale/dynamic-layers/freescale-layer/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-arm-extra/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/fsl-demos/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale/dynamic-layers/meta-netboot/recipes*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bb
/home/xxx/build-root/meta-freescale-3rdparty/recipes-*/*/*.bbappend
...



From: Nicolas Dechesne <nicolas.deche...@linaro.org>
Sent: Wednesday, May 24, 2017 11:19 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] dynamic-layers?

On Wed, May 24, 2017 at 12:30 PM, Takashi Matsuzawa <tmatsuz...@xevo.com> wrote:
> Hello, Yocto.
> I am a bit confused with dynamic-layers included in some of the recent
> layers in various BSPs.
>
> e.g.
>
> https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf

>
>># The .bbappend and .bb files are included if the respective layer
>># collection is available.
>>BBFILES += "${@'
>> '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' % layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' %
>> layer \
>>   for layer in BBFILE_COLLECTIONS.split())}"
>
> In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc.
> for conditional inclusion.
> And I think they are included only their names (browser-layer, etc.) are
> BBFILE_COLLECIONS.
>
> Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS
> when I want to include browser-layer in my build.
>
> Is it something to be done in my local.conf or customized distro conf file?

what that means is that recipe from the dynamic-layers/ will be
parsed/added *only if*  is already added in your build
environment. e.g. if you have meta-qt5 in BBLAYERS in
/conf/bblayers.conf, then the recipes from
"dynamic-layers/qt5-layer" are used as well.

This is mostly to allow a BSP layer to be used with as many
combinations of layers as possible.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] dynamic-layers?

[Takashi Matsuzawa]

Hello, Yocto.
I am a bit confused with dynamic-layers included in some of the recent layers 
in various BSPs.

e.g.

https://github.com/Freescale/meta-freescale/blob/master/conf/layer.conf

># The .bbappend and .bb files are included if the respective layer
># collection is available.
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' 
>% layer \
>   for layer in BBFILE_COLLECTIONS.split())}"
>BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % 
>layer \
>   for layer in BBFILE_COLLECTIONS.split())}"

In meta-freescale/dynamic-layers, there are browser-layer, efi-layer, etc. for 
conditional inclusion.
And I think they are included only their names (browser-layer, etc.) are 
BBFILE_COLLECIONS.

Question here is, who will be adding 'browser-layer' to BBFILE_COLLECTIONS when 
I want to include browser-layer in my build.

Is it something to be done in my local.conf or customized distro conf file?

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

Re: [yocto] 'and' combination for OVERRIDES values?

[Takashi Matsuzawa]

Hello.


>AAA_xxx_yyy = "true"

Thank you, I will try.  I could not figure out but I feel it should work.


From: Paul Eggleton <paul.eggle...@linux.intel.com>
Sent: Thursday, April 13, 2017 2:23 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] 'and' combination for OVERRIDES values?

On Thursday, 13 April 2017 12:16:08 PM NZST Takashi Matsuzawa wrote:
> I just wonder if there is convenient way of defining somthing in recipes
> based on combination of two OVERRIDES variables. Say, I have two variables
> xxx and yyy.
>
> AAA = "false"
> AAA_xxx = "true"
> AAA_yyy = "true"
>
> But what if I want to set AAA to be "true" only when xxx and yyy are in
> OVERRIDES? (And also for 'or' condition.)

This should work for "and":

AAA_xxx_yyy = "true"

(There was a time many releases ago where this didn't, but it should work in
any release in the last few years).

For "or" you already have the answer above, basically do it with the same
value for both overrides:

AAA = "false"
AAA_xxx = "true"
AAA_yyy = "true"

> The similar situation for do_install_append(), etc.
>
> do_install_append_xxx() {
> }
>
> do_install_append_yyy() {
> }

Same thing - for and:

do_install_append_xxx_yyy() {
}

for or:

do_install_append_xxx() {
}

do_install_append_yyy() {
}

Note, we're appending here rather than setting as above, but otherwise setting
a function is pretty much the same in terms of operations as a variable - the
syntax is slightly different and immediate operations (such as +=) aren't
allowed, but the same rules apply for overrides and deferred operations such
as _append.

Cheers,
Paul

--

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

[yocto] 'and' combination for OVERRIDES values?

[Takashi Matsuzawa]

Hello, Yocto.

I just wonder if there is convenient way of defining somthing in recipes based 
on combination of two OVERRIDES variables.
Say, I have two variables xxx and yyy.

AAA = "false"
AAA_xxx = "true"
AAA_yyy = "true"

But what if I want to set AAA to be "true" only when xxx and yyy are in 
OVERRIDES?
(And also for 'or' condition.)

The similar situation for do_install_append(), etc.

do_install_append_xxx() {
}

do_install_append_yyy() {
}


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

[yocto] a cmake recipe with subdirectories?

[Takashi Matsuzawa]

Hello, Yocto.
I wonder which is the common / recommended way of preparing a recipe for the 
following project?

I have a source tree with 2 subdirectories A, B.
Both A and B are cmake based source trees - each has CMakeLists.txt file of its 
own.
Then, when I build I would:

- checkout sync source for A and B
- build A (cd A; cmake; make)
- build B (cd ../B; cmake; make)

Where, build A produces headers and libraries to be used when building B.

Since this is rather a single software package, I want to make one Yhocto 
recipe that do the above A build and B build.

But looking into what cmake.bbclass does, it just configure against one 
CMakeList.txt and build tree?

I think writing two recipes for A and B, I can build them individually, but if 
I can I want to avoid it since it involves unpacking the same source tree 
twice, in two recipes.
(though, it will be somehow cached in bitbake procedure and it is not a 
complete duplicate..)

Any suggestion / coment is highly appreciated.


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

Re: [yocto] quoted string in a recipe variable?

[Takashi Matsuzawa]

I am sorry please ignore below.

I should put space after -D options so that cmake won't complain.


From: Takashi Matsuzawa
Sent: Friday, March 24, 2017 9:08 PM
To: yocto@yoctoproject.org
Subject: quoted string in a recipe variable?


Hello, Yocto.
I am a bit confused with recipe syntax for variable assignment.

I wanto embed double-quoted string within a variable.
And I tried below and looks like the whole part of the string (A to B) is 
successfully assigned to EXTRA_OECMAKE variable.

EXTRA_OECMAKE = " \ <-- A
  "-D CMAKE_= \
  ...
  ...
  -D CMAKE_=" \
" <-- B

My question is, if this is a valid way of doing it?
Why bitbake parser is not confused?


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

[yocto] quoted string in a recipe variable?

[Takashi Matsuzawa]

Hello, Yocto.
I am a bit confused with recipe syntax for variable assignment.

I wanto embed double-quoted string within a variable.
And I tried below and looks like the whole part of the string (A to B) is 
successfully assigned to EXTRA_OECMAKE variable.

EXTRA_OECMAKE = " \ <-- A
  "-D CMAKE_= \
  ...
  ...
  -D CMAKE_=" \
" <-- B

My question is, if this is a valid way of doing it?
Why bitbake parser is not confused?


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

[yocto] epiphany for wayland only environemnt?

[Takashi Matsuzawa]

Hello, Yocto.


I have looked into recipes index, etc. but I so far I could not figure out 
clear answer, so if you have status on this, I highly appreciate.


I am looking for a web browser that can (without much effort) be built and run 
on Yocto based environment, with wayland-only window system (without x11 
libraries).


i.e. if such Yocto recipe already exist, it would be a great help.

I can see midori, epiphay, or other browser 'should run' on wayland 
environment, but it seems they rely graphics libraries that still depends on 
x11 and in Yocto recipes x11 DISTRO_FEATURES is being set as requirement for 
them.


Is this still the situation on latest master or morty branches.

If there is an attempt for the similar?

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

Re: [yocto] hddimg 4GB limit?

[Takashi Matsuzawa]

Hello.

I found hddimg 4GB-1 bye restriction because it creates a file called 
rootfs.img which is copied into FAT.

That means rootfs.img size must be below FAT max file size...



From: Takashi Matsuzawa
Sent: Thursday, March 9, 2017 1:51 PM
To: yocto@yoctoproject.org
Subject: hddimg 4GB limit?


Hello, Yocto.


I have looked into hddimg file.

According to image-live.bbclass, it is hardcoded to maximum 4GB size.

But should not this more large?

hddimg is generated by mkdosfs -F 32 that means the filesystem capacity is 
larger than 4GB.


I just hit this limit when generating an image that exceeds 4GB size.


I think I am look into using hdddirect instead (hopefully it does not have this 
limit?),

but I also want to check if hddimg 4GB limitation has some practical reason 
(other than above image-live.bbclass checking).

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

[yocto] hddimg 4GB limit?

[Takashi Matsuzawa]

Hello, Yocto.


I have looked into hddimg file.

According to image-live.bbclass, it is hardcoded to maximum 4GB size.

But should not this more large?

hddimg is generated by mkdosfs -F 32 that means the filesystem capacity is 
larger than 4GB.


I just hit this limit when generating an image that exceeds 4GB size.


I think I am look into using hdddirect instead (hopefully it does not have this 
limit?),

but I also want to check if hddimg 4GB limitation has some practical reason 
(other than above image-live.bbclass checking).

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

[yocto] Placing xxxx.pc in nativesdk?

[Takashi Matsuzawa]

Hello, Yocto.

Maybe a basic question but I am being puzzled.


i) Recipe A builds module, and the module expects that xkbcommon.pc is 
available (checked in autotool by calling pkg-config)

ii) module A build fails, since it cannot find xkbcommon.pc, according to the 
config.log.


(in TEMPDIR/work)
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/image/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/sysroot-destdir/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/build/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/packages-split/libxkbcommon-dev/usr/lib/pkgconfig/xkbcommon.pc
./cortexa9hf-neon-poky-linux-gnueabi/libxkbcommon/0.5.0-r0/package/usr/lib/pkgconfig/xkbcommon.pc

I can find it above, but I do not seem to find it in x86_64-nativesdk-x 
tree, so it may be the cause of the problem.
The recipe A has DEPENDS that include "libxkbcommon"

My question is, in general, what is lacking here that prevent xkbcommon.pc to 
be found from other recipe / configure?

.pc is in the target image /isr/lib/pkgconfig successfully, so I believe I 
need something to make it available in cross SDK?


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

Re: [yocto] meta-efl build?

[Takashi Matsuzawa]

Hello.

Thank you very much for the pointer, but I think this image is x11 based..

I can see EFL project has some pages mentioning about booting EFL on 
wayland-only environment, but it is not yocto (or oe) based instruction.


From: Khem Raj <raj.k...@gmail.com>
Sent: Thursday, February 16, 2017 11:53 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] meta-efl build?

Takashi-san

On Wed, Feb 15, 2017 at 6:35 PM, Takashi Matsuzawa <tmatsuz...@xevo.com> wrote:
> Hello, Yocto.
>
>
> I am trying to build EFL on top of my mayland environment (krogoth based).
>
> I thought it would be easy since there is meta-openembedded/meta-efl
> recipes, but now I am stuck.
>
>
> Specifically, I am experiencing x11 dependency (the recipes erquire x11 to
> be in DISTRO_FEATURES here and elsewhere), but for my target I am settting
> wayland only, no x11.
>
> (e.g. it says it needs libxcb, etc.)
>
>
> Is it normal and I am failing to configure it properly?
>
>
> I found below, but it does not talk much about the build errors I am facing,
> and if the targets I am specifying is correct, etc.
>
>
> https://www.enlightenment.org/distros/yocto-start
Yocto - Enlightenment Main<https://www.enlightenment.org/distros/yocto-start>
www.enlightenment.org
In Yocto, a meta-efl layer is provided by the meta-openembedded layer. It 
contains EFL, Elementary, Enlightenment, Terminology and other recipes.



>
> If you are aware of any previous attempt, or, guide that I just overlooked
> for my laziness - I highly appreciate your pointers.
>

Using some preexisting image like angstrom one would be a good start
for you e.g.

https://github.com/Angstrom-distribution/meta-angstrom/blob/master/recipes-images/angstrom/efl-nodm-image.bb
meta-angstrom/efl-nodm-image.bb at master · Angstrom-distribution/meta-angstrom 
· 
GitHub<https://github.com/Angstrom-distribution/meta-angstrom/blob/master/recipes-images/angstrom/efl-nodm-image.bb>
github.com
meta-angstrom - MIrror of Angstrom metadata layer




it should work if you were to use angstrom distribution but if you
dont it should serve a good jump start.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-efl build?

[Takashi Matsuzawa]

Hello, Yocto.


I am trying to build EFL on top of my mayland environment (krogoth based).

I thought it would be easy since there is meta-openembedded/meta-efl recipes, 
but now I am stuck.


Specifically, I am experiencing x11 dependency (the recipes erquire x11 to be 
in DISTRO_FEATURES here and elsewhere), but for my target I am settting wayland 
only, no x11.

(e.g. it says it needs libxcb, etc.)


Is it normal and I am failing to configure it properly?


I found below, but it does not talk much about the build errors I am facing, 
and if the targets I am specifying is correct, etc.


https://www.enlightenment.org/distros/yocto-start


If you are aware of any previous attempt, or, guide that I just overlooked for 
my laziness - I highly appreciate your pointers.

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

Re: [yocto] genericx86 vs qemux86

[Takashi Matsuzawa]

Hello, thank you for your reply.


I wondered vmware or virtuaobox, etc. are doing something already so that the 
environment looks like a real PC.  You can run commercial OS like Windows on it 
and they are no particularly built for the emulation environment.


On the other hand, qemux86* builds are 'safe' version that means limitation in 
its performance (hardware acceleration, etc.)?

So, if virtualization platform provides what intel-core* builds expects, then I 
will see a better performance with them, rather thatn qemu* builds.
Or qemu* builds provide particular features that suites well with VM, other 
thna its 'safe' behavior?

That is my concern.




From: Burton, Ross <ross.bur...@intel.com>
Sent: Saturday, February 4, 2017 8:20 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] genericx86 vs qemux86


On 3 February 2017 at 23:16, Takashi Matsuzawa 
<tmatsuz...@xevo.com<mailto:tmatsuz...@xevo.com>> wrote:
Sorry, I am still a bit confused with genericx86 and qemux86 targets.  What is 
their difference and which one to choose.
Both are x86 target and maybe genericx86 has more support for PC hardware?  
qemux86 has v86d?
genericx86 is from poky and qemux86 is from openembeded?

qemux86 is specifically for use in qemu, so it targets a CPU that qemu is good 
at executing and has the virtualised hardware drivers in.  genericx86 is an 
attempt at a "all purpose" x86 machine that runs most places acceptably.

My recommendation would be to use qemux86 (-64) for virtual environments and a 
machine from meta-intel (intel-corei7-64 or intel-core2-32) for real hardware.  
The genericx86 machine, being part of poky, is basically for QA purposes and if 
you are targetting Intel hardware then the Intel BSPs are better.

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

[yocto] genericx86 vs qemux86

[Takashi Matsuzawa]

Hello, Yocto.

Sorry, I am still a bit confused with genericx86 and qemux86 targets.  What is 
their difference and which one to choose.
Both are x86 target and maybe genericx86 has more support for PC hardware?  
qemux86 has v86d?
genericx86 is from poky and qemux86 is from openembeded?

I am making x86 image for virtual environment and maybe PCs, so I wanted to 
know the pros/cons of these two.


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

Re: [yocto] Ruby and OpenSSL version mismatch?

[Takashi Matsuzawa]

Hello, I just tried and the below seems to be the fix.


https://patchwork.openembedded.org/patch/11/


From: Takashi Matsuzawa
Sent: Thursday, February 2, 2017 3:25 PM
To: yocto@yoctoproject.org
Subject: Ruby and OpenSSL version mismatch?


Hello, Yocto.

I am trynig a build of fido based yocto image, with openssl 1.0.2j for security 
reason.
The openssl recipe itself builds successfully, but later in the build I see 
error in jscore.
In fact, ruby is complaining that 'OPENSSL_1.0.0' is not available.

| 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
 `require': 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/../../../../libcrypto.so.1.0.0:
 version `OPENSSL_1.0.0' not found (required by 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so) 
- /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so 
(LoadError)
| from 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
 `require'
| from 
/xxx/work/core2-32-poky-linux/qtwebkit/5.5.0+gitAUTOINC+0d592678ba-r0/git/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb:30:in
 `'
| make[2]: *** [LLIntDesiredOffsets.h] Error 1

In fact, if I do objdump -p on sha1.so (in ruby tree):

>  required from libcrypto.so.1.0.0:
>0x066a2b20 0x00 02 OPENSSL_1.0.0

Whereas, my libcrypt.so.1.0.0 says:

>Version definitions:
>1 0x01 0x0746be50 libcrypto.so.1.0.0
>2 0x00 0x06a2b2e4 OPENSSL_1.0.2d
>3 0x00 0x06a2b2e7 OPENSSL_1.0.2g
>OPENSSL_1.0.2d

So, this might be the cause of the problem.
But I am not sure why sha1.so (which ruby build generats) define these version 
numbers and not refer to the OpenSSL library in the build.

I googled, but there were some tips on updating ruby to solve OpenSSL version 
mismatch, but it is through grew or apt-get, etc.  Not a tip for yocto build.

I may be not familiar with ruby build yet, but any idea how I can fix this?
I could try updating ruby recipe as well to more recent version, but first I 
want to confirm how ruby is deciding the OpenSSL version for its plugin library 
and causing this mismatch.

Thank you for your knowledge..

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

[yocto] Undoing BSP's BBMASK?

[Takashi Matsuzawa]

Hello Yoct.

Say, BSP defines something like this.

BBMASK .= "|msta-//.bb"

Then I want to cancel this within my local.conf.  Should putting below in my 
local.conf works? (Or within my bistro/.conf?)

BBMASK_remove = "|msta-//.bb"


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

[yocto] Ruby and OpenSSL version mismatch?

[Takashi Matsuzawa]

Hello, Yocto.

I am trynig a build of fido based yocto image, with openssl 1.0.2j for security 
reason.
The openssl recipe itself builds successfully, but later in the build I see 
error in jscore.
In fact, ruby is complaining that 'OPENSSL_1.0.0' is not available.

| 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
 `require': 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/../../../../libcrypto.so.1.0.0:
 version `OPENSSL_1.0.0' not found (required by 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so) 
- /xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/x86_64-linux-gnu/digest/sha1.so 
(LoadError)
| from 
/xxx/sysroots/x86_64-linux/usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in
 `require'
| from 
/xxx/work/core2-32-poky-linux/qtwebkit/5.5.0+gitAUTOINC+0d592678ba-r0/git/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb:30:in
 `'
| make[2]: *** [LLIntDesiredOffsets.h] Error 1

In fact, if I do objdump -p on sha1.so (in ruby tree):

>  required from libcrypto.so.1.0.0:
>0x066a2b20 0x00 02 OPENSSL_1.0.0

Whereas, my libcrypt.so.1.0.0 says:

>Version definitions:
>1 0x01 0x0746be50 libcrypto.so.1.0.0
>2 0x00 0x06a2b2e4 OPENSSL_1.0.2d
>3 0x00 0x06a2b2e7 OPENSSL_1.0.2g
>OPENSSL_1.0.2d

So, this might be the cause of the problem.
But I am not sure why sha1.so (which ruby build generats) define these version 
numbers and not refer to the OpenSSL library in the build.

I googled, but there were some tips on updating ruby to solve OpenSSL version 
mismatch, but it is through grew or apt-get, etc.  Not a tip for yocto build.

I may be not familiar with ruby build yet, but any idea how I can fix this?
I could try updating ruby recipe as well to more recent version, but first I 
want to confirm how ruby is deciding the OpenSSL version for its plugin library 
and causing this mismatch.

Thank you for your knowledge..

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

Re: [yocto] patching .bbclass files?

[Takashi Matsuzawa]

Well, doing repo -diff and apply produced patch when I newly repo sync could 
work.


https://groups.google.com/forum/#!topic/repo-discuss/43juvD1qGIQ



From: Takashi Matsuzawa
Sent: Monday, January 30, 2017 11:00 AM
To: yocto@yoctoproject.org
Subject: patching .bbclass files?


Hello Yocto
I am curious if there is a better way of doing this manually every time I 
re-synch to Yocto based BSP.

Say, I have a patch or customization I want to try on .bbclass files (instead 
of .bb or .bbappend, or the source files that are fetched.)
The reason for this is sometimes I want to try the latest fix to the BSP while 
building old versino of my image, or debbuging image by modifying the build 
system files.

I think by using .bbappend files I can try modification to the .bb file 
behaviros, but it does not for .bbclass files.
I could add slightly modified xxx.bbclass to my own layer so that it may 
override what is available in poky/meta/..., but it may mean I just duplicate a 
lot of bitbake related files in my layer for just a few lines of changes.

'repo' having a feature copying files when repositories are synched.  This may 
work for me?

Ideally, the poky and other remote gits have branches or releases that have the 
patches I want to try, or I should be using the latest releases that should 
include meaningful fixes already.
But it is not possible always.

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

Re: [yocto] pkg_postinst shell?

[Takashi Matsuzawa]

Hello.
It seems the below patch fixes this problem.

systemd.bbclass: don't block on service restart
https://patchwork.openembedded.org/patch/134317/

(By the way, it may related to my question in another thread, but which is the 
convenient way to apply this kind of patches to my local build system?)


From: Takashi Matsuzawa
Sent: Saturday, January 28, 2017 11:58 AM
To: yocto@yoctoproject.org
Subject: pkg_postinst shell?


Hello Yocto.
I am debugging my recipe, which uses pkg_postinst but does not seem to work as 
expected.

It runs fine without $D detection.
However, if I try to run it at first boot (skipping with exit 1 if $D is not 
empty), the board boot seems to hang.
I think error (syntax error, etc.?) happening when it is run on the board, but 
package manager.

I doubt it is caused by non-existence of '#!/bin/sh' in my script but I am not 
sure since I am still trying the builds again and again.

i) Regarding the posttest script execution, is there log available so that I 
can look into (instead of writing out log file by myself from within my 
script)?  I do not seem to find it in temp folder of my recipes's working 
directory.

ii) Is '#!/bin/sh' always necessary?

iii) What happens with pkg_postinst_PN_append?  If it is defined without 
pkg_postinst_PN, it still works and executed?  If i) is true what about 
'#!/bin/sh' in this case?

If you have qucik suggestions, it is a great help.



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

[yocto] patching .bbclass files?

[Takashi Matsuzawa]

Hello Yocto
I am curious if there is a better way of doing this manually every time I 
re-synch to Yocto based BSP.

Say, I have a patch or customization I want to try on .bbclass files (instead 
of .bb or .bbappend, or the source files that are fetched.)
The reason for this is sometimes I want to try the latest fix to the BSP while 
building old versino of my image, or debbuging image by modifying the build 
system files.

I think by using .bbappend files I can try modification to the .bb file 
behaviros, but it does not for .bbclass files.
I could add slightly modified xxx.bbclass to my own layer so that it may 
override what is available in poky/meta/..., but it may mean I just duplicate a 
lot of bitbake related files in my layer for just a few lines of changes.

'repo' having a feature copying files when repositories are synched.  This may 
work for me?

Ideally, the poky and other remote gits have branches or releases that have the 
patches I want to try, or I should be using the latest releases that should 
include meaningful fixes already.
But it is not possible always.

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

[yocto] pkg_postinst shell?

[Takashi Matsuzawa]

Hello Yocto.
I am debugging my recipe, which uses pkg_postinst but does not seem to work as 
expected.

It runs fine without $D detection.
However, if I try to run it at first boot (skipping with exit 1 if $D is not 
empty), the board boot seems to hang.
I think error (syntax error, etc.?) happening when it is run on the board, but 
package manager.

I doubt it is caused by non-existence of '#!/bin/sh' in my script but I am not 
sure since I am still trying the builds again and again.

i) Regarding the posttest script execution, is there log available so that I 
can look into (instead of writing out log file by myself from within my 
script)?  I do not seem to find it in temp folder of my recipes's working 
directory.

ii) Is '#!/bin/sh' always necessary?

iii) What happens with pkg_postinst_PN_append?  If it is defined without 
pkg_postinst_PN, it still works and executed?  If i) is true what about 
'#!/bin/sh' in this case?

If you have qucik suggestions, it is a great help.



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

[yocto] DISTRO_FEATURES vs IMAGE_FEATURES

[Takashi Matsuzawa]

Hello Yocto.
Though it may feel to me matter of taste, is there suggestion on when which of 
these to use when you need to define your customized feature.

DISTRO_FEATURES seems to be more relaxed, you can define things in your distro 
conf.
IMAGE_FEATURE seems to be more strict, and you need to add your item also as 
one of the 'validitems', unless you use it through FEATURE_PACKAGES.
(Or this is not needed when you use EXTRA_IMAGE_FEATURES?)

These two just mean one if for DISTRO associated features and another for your 
image - it is all that?

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

[yocto] SRC_URI patch slection

[Takashi Matsuzawa]

Hello.

I have following recipe files and want to remove .patch added to SRC_URI at 
ii).


i) _git.bb - specifies RC_URI revision by SRCREV parameter

ii) _%.bbappend - adds several .patch to SRC_URI

iii) _%.bbappend - my recipe


I want  to make it (removal) conditional to SRCREV value.

i), ii) and iii) are maintained by 3 different people, and .patch is needed 
or not needed according to the source revision.


In other words, in my iii) recipe I could say SRC_URI_remove = 
"file://.patch", but I want to make it only for specific SRCREV revisions.

Or any other way of writing my iii) recipe for this?


Thank you very much for your advice.

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

Re: [yocto] live" image: iso and ext4 artifacts

[Takashi Matsuzawa]

Hello.


Thanks it worked for .iso files.


I have found that this really is a save for build time also.


From: Jussi Kukkonen <jussi.kukko...@intel.com>
Sent: Friday, December 16, 2016 6:22 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] live" image: iso and ext4 artifacts

On 15 December 2016 at 09:30, Takashi Matsuzawa 
<tmatsuz...@uievolution.com<mailto:tmatsuz...@uievolution.com>> wrote:
>
> Hello Yocto.
>
> I am trying x86-64 BSP image (based on jethro version).
> It has following root filesystem type, and it generats .hddimg file that 
> I am using.
>
> > IMAGE_FSTYPES = "live"
>
> The issue is that in addition to .hddimg, it produces following image 
> files and it sometimes cause lack of disk space error on my build PC.
>
> > 2422489088 -intel-corei7-64-20161215004421.hddimg
> > 2402287616 -intel-corei7-64-20161215004421.iso
> > 2368578560 -intel-corei7-64-20161215004421.rootfs.ext4
>
> I do not need xxx.iso and .ext4 files as final output, though I 
> understand that .ext4 file may have been used to produce xxx.hddimg file.

I think you should be able to define NOISO=1.

The rootfs is indeed used to produce the actual images, you could delete it 
afterwards... but before you spend valuable time writing shell scripts, 
consider a new SSD: 500GB is probably less than 150EUR by now.

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

[yocto] live" image: iso and ext4 artifacts

[Takashi Matsuzawa]

Hello Yocto.

I am trying x86-64 BSP image (based on jethro version).
It has following root filesystem type, and it generats .hddimg file that I 
am using.

> IMAGE_FSTYPES = "live"

The issue is that in addition to .hddimg, it produces following image files 
and it sometimes cause lack of disk space error on my build PC.

> 2422489088 -intel-corei7-64-20161215004421.hddimg
> 2402287616 -intel-corei7-64-20161215004421.iso
> 2368578560 -intel-corei7-64-20161215004421.rootfs.ext4

I do not need xxx.iso and .ext4 files as final output, though I understand 
that .ext4 file may have been used to produce xxx.hddimg file.

I think "live" image type is special since I do not have .live file but the 
live-image class may be generating such extra images files (so I cannot just 
specify hddimg as IMAGE_FSTYPES).

I have the similar issue with the other types of BSP (e.g. I only need 
.sdcard image, but I have other image types), but to begin with, I want to 
reduce sized files that I do not need in x86-64 builds.

Highly appreciate if you have any advice.
(I can manually remove .iso and .ext4 files when the build is 
completed, but they exists during the build so I also will meed lack of disk 
space error in such attempt).

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

[yocto] Py_ENABLE_SHARED in Python cross-build

[Takashi Matsuzawa]

Hello Yocto.

I recently encountered following issue with Python module cross-build.
(On Yocto 2.0 based build system, using distutils.bbclass)

http://bugs.python.org/issue28421

Firstly I believed it is a Python issue, but further looked into, Yocto build 
environment has some cutomization causing this.

1) Python checks existence of Py_ENABLE_SHARED flag by calling sysconfig.py 
function.
This flag is loaded from pyconfig.h by sysconfig.py:parse_config_h().

2) If Py_ENABLE_SHARED is present, it properly add -L and -lpython2.7 LD flags 
to gcc command line.
But I cannot see thse are being added and my Python module cross-build fails.

3) For pyconfig.h generation to the cross target, Yocto build tools callign 
oe_multilib_header() which makes modification to pyconfig.h file, which 
unfortunately results #ifdef/#include directives
which cannot be parsed by sysconfig.py:parse_config_h()

Is this something likely to be addressed by now?

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

Re: [yocto] BBMASK does not work

[Takashi Matsuzawa]

OK, I figured this out that I can add my BBMASK lines to my 
conf/distro/xxx.conf fille.

So that I can append to what BSP defines and it seems to happen before 
collect_bbbfiles() function.

Sorry for my confusion.


From: Takashi Matsuzawa
Sent: Friday, September 16, 2016 6:13 PM
To: yocto@yoctoproject.org
Subject: Re: BBMASK does not work


Well, I tried adding debug lines to poky/bitbake/lib/bb/cooker.py, and I think 
what is happening is:

i) BSP has BBMASK =  line.
ii) I add BBMASK_forcevariable =  line to my local.conf
iii) If I check with -e option, I can see BBMASK variable is finally set to 
""
iv) However, when cooker.py is run, matching bbmask file list with recipe 
paths, the original "" line is used for matching.

I feel, the recipe files matching is being done before BBMASK is finally set to 
"".  Instead, they are matches against "" it is the initial BBMASK 
value set by BSP.

This is fido, and jethro may be behave differently (since on jethro based build 
this seemed to work)?

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

Re: [yocto] BBMASK does not work

[Takashi Matsuzawa]

Well, I tried adding debug lines to poky/bitbake/lib/bb/cooker.py, and I think 
what is happening is:

i) BSP has BBMASK =  line.
ii) I add BBMASK_forcevariable =  line to my local.conf
iii) If I check with -e option, I can see BBMASK variable is finally set to 
""
iv) However, when cooker.py is run, matching bbmask file list with recipe 
paths, the original "" line is used for matching.

I feel, the recipe files matching is being done before BBMASK is finally set to 
"".  Instead, they are matches against "" it is the initial BBMASK 
value set by BSP.

This is fido, and jethro may be behave differently (since on jethro based build 
this seemed to work)?

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

[yocto] BBMASK does not work

[Takashi Matsuzawa]

Hello, Yocto.
I am quite puzzled with this and spent a few hours today so far.
In case you have any comment or suggestion, it would be a great help.

I am trying to hide one of the .bbappend files from the tree, so that BB 
won't complain "ERROR: No recipes available for:" error.

I did add several forms of the lines for this in BBMASK variable, but somehow 
BB seems to find it and complain "ERROR: no recipes available for:".

e.g.

Fido based build tree.
Want to hide _1.2.3.bbappend since there is no _1.2.3.bb recipe in my 
tree.

BBMASK = ".*/_%.bbappend"
BBMASK = ".*/_1.2.3.bbappend"
...

I tried BBMASK_forcevariable, and "-e" option to make sure they are set in 
BBMASK.

I further tried to set ".*" to BBMASK (so that the error message will be 
changed and I can see BBMASK is working), but the error message is still the 
same.  It says there is no recipes for _1.2.3.bbappend.

(But, if I manually rename _1.2.3.bbappend to, say, _1.2.3.bbappendx, 
error message is gone.)

Well, what I can do to debug and diagnose why this is happening.
I believed BBMASK worked as expected, and I think the other build tree I have 
does not have this problem.

Deleting state cache does not seem to change anything..



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

Re: [yocto] ac_cv_sizeof_long size definition by SDK

[Takashi Matsuzawa]

Hello.

I further gathered info and filed bellow.

(This is the first time I file a case against yoctoproject bugzilla, so please 
point me if anything is not in convention.)


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


From: Mark Hatle <mark.ha...@windriver.com>
Sent: Friday, September 9, 2016 11:46 PM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] ac_cv_sizeof_long size definition by SDK

On 9/9/16 6:33 AM, Takashi Matsuzawa wrote:
> Hello, Yocto.
>
>
> I am now puzzled by this variable ste in $CONFIG_SITE setup file in
> Yocto-generated SDK.
>
>
> I generated x86_64 host, arm (32bit) target SDK.
>
> And if I invoke $CC (arm-poky-linux-gnueabi-gcc), using this SDK, sizeof 
> (long)
> is 4 (long = int)
>
>
> However, if I look into $CONFIG_SITE's definition of ac_cv_sizeof_long, it is
> defined as '8'.
>
> I feel this is strange since if this cached configure data is for the target
> (and cross-compiling), this value should be 4, to match the above
> (arm-poky-linux-gnueabi-gcc) result.
>
> (I think this part of the cache is being copied from 
> poky/meta/site/x86_64-linux, )

There should be multiple caches.  There may be one for the host (nativesdk) and
one for each target (arm 32-bit).

Once you load the environment file for the arm system, the CONFIG_SITE setting
should point to the proper settings for the environment file you have loaded.

In a Power (32-bit) SDK I had laying around:

sourcing "environment-setup-powerpc-linux"

results in:

CONFIG_SITE=.../sdk/site-config-powerpc-linux

if I look at that file:

ac_cv_sizeof_long=${ac_cv_sizeof_long=4}

which is the correct value.


If this is NOT what you are seeing in your generated SDKs, and you are loading
the proper environment file, please file a defect with the Yocto Project
version, your configuration information and a way to reproduce the problem.

--Mark

>
> This is causing break if I build autotool based program using the SDK.
>
>
> Am I doing mis-use of SDK here?
>
>
>
>
>

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

[yocto] ac_cv_sizeof_long size definition by SDK

[Takashi Matsuzawa]

Hello, Yocto.


I am now puzzled by this variable ste in $CONFIG_SITE setup file in 
Yocto-generated SDK.


I generated x86_64 host, arm (32bit) target SDK.

And if I invoke $CC (arm-poky-linux-gnueabi-gcc), using this SDK, sizeof (long) 
is 4 (long = int)


However, if I look into $CONFIG_SITE's definition of ac_cv_sizeof_long, it is 
defined as '8'.

I feel this is strange since if this cached configure data is for the target 
(and cross-compiling), this value should be 4, to match the above 
(arm-poky-linux-gnueabi-gcc) result.

(I think this part of the cache is being copied from 
poky/meta/site/x86_64-linux, )


This is causing break if I build autotool based program using the SDK.


Am I doing mis-use of SDK here?


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

[yocto] pkg_postinst behavior?

[Takashi Matsuzawa]

Hello, Yocto.
I just want to confirm how pkg_postinst scripts are called.

Provided the following scripts are provided, in two bbappend recipes as below, 
which of them are actually executed and which are not?
I have briefly tried and 'OK's below are called and 'NG's are not.

The yocto manual says posttest scripts must be suffixed by package names, but 
which package names?
postinst scripts with package names from the other recipe (script in AAA 
referring BBB package name) can be invoked at BBB package installation?

AAA.bbappend:

pkg_postinst_AAA() {} - OK
pkg_postinst_AAA_append() {} - OK
pkg_postinst_BBB() {} - NG
pkg_postinst_BBB_append() {} - NG

BBB.bbappend:

pkg_postinst_AAA() {} - NG
pkg_postinst_AAA_append() {} - NG
pkg_postinst_BBB() {} - OK
pkg_postinst_BBB_append() {} - OK

And, multiple _append() once could be added, but if _append() is not there only 
one of such script for the same name is executed?

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

[yocto] vlc experience?

[Takashi Matsuzawa]

Hello Yocto.

I am trying to build and run vlc on my fido based environment (genericx86 
machine), but so far failing to play most of the multimedia files.
I just wonder any of you have similar experience and hopefully has a clue.

vlc player build OK without problem, by just adding vlc by 
IMAGE_INSTALL_append, vlc recipe version is vlc_2.1.4, and I can launch it from 
sat desktop, and select files to be played.

But, When I tried the following multimedia samples, I cannot play most of them.

xxx.mp3 - NG (mega not support)
http://www.gomplayer.jp/img/sample/mp4_h264_aac.mp4 - NG (h264 not support)
http://www.gomplayer.jp/img/sample/mp4_mpeg4_aac.mp4 - NG (mp4v not support)
http://www.gomplayer.jp/img/sample/mpeg2_mpeg2_ac3.mpg - NG (video only, a52 
not support)
http://www.gomplayer.jp/img/sample/mpeg2_mpeg2_lpcm.mpg - OK (mpg and llcm 
supported)

The error message I get is the following.

"No suitable decoder module:
VLC does not support the audio or video format "mpga". Unfortunately there is 
no way for you to fix this."

I googled for this and a few suggestions on various forums are that you may 
need additional codecs installed.
But as I inspect by vlc --list-verbose, and also look into /usr/lib/vlc/plugins 
folder, I believe modules corresponding to mega, h264, mp4v, a52 are there.
(At least, these names are listed in the list and corresponding module files 
are there.)

I have looked into the vlc source, and I think its codec selection mechanism is 
related to its own var_ variable database, but may need more time to learn 
(and compare) how it should be working.

Well, in case if there is any known information related this, I highly 
appreciated.
I want a media player that I can use for my apps's testing (as a reference).



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

[yocto] debugging pkg_postinst?

[Takashi Matsuzawa]

Hello Yocto.

This may be a novice question, but just in case you have suggestion:


Debugging pkg_postinst script is simply taking time for me, since I wait rootfs 
creation to confirm its result.

This is a overkill since rpm creation is just a few min, but generating whole 
rootfs takes hours.

I wonder if there is a better way to do this.


I imagine trying install of individual rpm file on target may give me 
information (since rpm installation shall run postinst script as well).

But, rather, it would be handy if I can invoke bitbake command and let it just 
run rootfs portion of my component.

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

Re: [yocto] BBMASK issue

[Takashi Matsuzawa]

Hello.


>Please note that BBMASK was changed in Krogoth to allow multiple regular
>expressions (see commit a948f5252 in Poky). Basically, with Krogoth and
>later you can do:
>
>BBMASK = "aaa bbb ccc"
>BBMASK += "ddd eee"
>BBMASK_append = " fff ggg"


This is good, since everyone can always do append, not overwriting someone's 
definition.


For now (for my pre-2.1 build), I ended up to copy BSP's BBMASK definition to 
my local.conf to include everything.

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

[yocto] BBMASK issue

[Takashi Matsuzawa]

Hello Yocto.

Now I am trying to customize an existing BSP to my need.
For this, I am adding following to my local.conf so that some of the recipes in 
the BSP to be ignored.

(local.conf)
BBMASK = "aaa|bbb|ccc"
BBMASK .= "|ddd|eee"

However, it does not work since BSP itself has lines like below in its layer.

(somelayer.conf)
BBMASK = "xxx|yyy|xxx"

The BSP definition of BBMASK seems to be overwriting my BBMASK definition in my 
local.conf.
I wonder what is the best way so that the both definition are effective.

I confirmed modifying BSP's definition as below works, but not sure if this can 
be recommended as practice to everyone who provides layers for their BSPs.

BBMASK .= "|xxx|yyy|xxx"


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

Re: [yocto] autotool __init_array_end not found

[Takashi Matsuzawa]

Well, I could workaround below by patching configure.ac of the package.

May not really have been an yocto issue..


From: Takashi Matsuzawa
Sent: Friday, July 22, 2016 1:01 PM
To: yocto@yoctoproject.org
Subject: autotool __init_array_end not found


Hello Yocto.

I am now trying to build autotool based (inherit autotool) recipe on Yocto 2.0 
based environent.
Howerver, I am seeng following error.
I wonder if this is a known problem and you already have workaround?

It says __init_array_end/start is not found which is referred in 
libc_nonshared.a(elf-init.oS).
I googled and learned that this can happen if parameters are not set properly 
to g++ when building shared library, and in fact, if I remove '-lc' from the 
final linker command line, the build error is gone.

>-lm -lc -lgcc_s -lgcc => NG
>-lm -lgcc_s -lgcc => OK

The problem is, these liker parameters are set by the configure script into 
libtool script and so far I could not find easy configurable option to 
explicity remove '-lc' from here.

I think configure recognizes that '-lc' is not necessary to build shared 
library (through 'build_libtool_need_lc', etc. test), but it takes these from 
somewhere (from its tests or its default template?) and embedding to linker 
command parameters.

This error did not happen with Yocto 1.8 based build (where the same recipe 
could built w/o break).
So, it can be toolchain issue (c library difference, autotool difference, etc.) 
or libc quirk, maybe fixed problem in recent versions, or specific to my 
cross-environment, but I have not yet figured out handy workaround.

I am trying here with protobuf package, butI am not yet sure if this happens 
with all of the autotool based packages.


| arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-g++
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter  -fPIC
-DPIC -shared -nostdlib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/Scrt1.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crti.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtbeginS.o
 google/protobuf/stubs/.libs/atomicops_internals_x86_gcc.o
google/protobuf/stubs/.libs/atomicops_internals_x86_msvc.o
[...]
google/protobuf/io/.libs/zero_copy_stream_impl.o
google/protobuf/compiler/.libs/importer.o
google/protobuf/compiler/.libs/parser.o   -lpthread -lz
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/lib
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libstdc++.so
-lm -lc -lgcc_s -lgcc
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtendS.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crtn.o
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter -pthread
-O2 -g -fstack-protector-all -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread -Wl,-soname
-Wl,libprotobuf.so.10 -o .libs/libprotobuf.so.10.0.0
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
.libs/libprotobuf-lite.so.10.0.0: hidden symbol `__init_array_end'
isn't defined
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:1492: recipe for target 'libprotobuf-lite.la' failed
| make[3]: *** [libprotobuf-lite.la] Error 1
| make[3]: *** Waiting for unfinished jobs
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-l

[yocto] autotool __init_array_end not found

[Takashi Matsuzawa]

Hello Yocto.

I am now trying to build autotool based (inherit autotool) recipe on Yocto 2.0 
based environent.
Howerver, I am seeng following error.
I wonder if this is a known problem and you already have workaround?

It says __init_array_end/start is not found which is referred in 
libc_nonshared.a(elf-init.oS).
I googled and learned that this can happen if parameters are not set properly 
to g++ when building shared library, and in fact, if I remove '-lc' from the 
final linker command line, the build error is gone.

>-lm -lc -lgcc_s -lgcc => NG
>-lm -lgcc_s -lgcc => OK

The problem is, these liker parameters are set by the configure script into 
libtool script and so far I could not find easy configurable option to 
explicity remove '-lc' from here.

I think configure recognizes that '-lc' is not necessary to build shared 
library (through 'build_libtool_need_lc', etc. test), but it takes these from 
somewhere (from its tests or its default template?) and embedding to linker 
command parameters.

This error did not happen with Yocto 1.8 based build (where the same recipe 
could built w/o break).
So, it can be toolchain issue (c library difference, autotool difference, etc.) 
or libc quirk, maybe fixed problem in recent versions, or specific to my 
cross-environment, but I have not yet figured out handy workaround.

I am trying here with protobuf package, butI am not yet sure if this happens 
with all of the autotool based packages.


| arm-poky-linux-gnueabi-libtool: link: arm-poky-linux-gnueabi-g++
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter  -fPIC
-DPIC -shared -nostdlib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/Scrt1.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crti.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtbeginS.o
 google/protobuf/stubs/.libs/atomicops_internals_x86_gcc.o
google/protobuf/stubs/.libs/atomicops_internals_x86_msvc.o
[...]
google/protobuf/io/.libs/zero_copy_stream_impl.o
google/protobuf/compiler/.libs/importer.o
google/protobuf/compiler/.libs/parser.o   -lpthread -lz
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/lib
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0
-L/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libstdc++.so
-lm -lc -lgcc_s -lgcc
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/arm-poky-linux-gnueabi/5.2.0/crtendS.o
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/crtn.o
-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15
--sysroot=/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter -pthread
-O2 -g -fstack-protector-all -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread -Wl,-soname
-Wl,libprotobuf.so.10 -o .libs/libprotobuf.so.10.0.0
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
.libs/libprotobuf-lite.so.10.0.0: hidden symbol `__init_array_end'
isn't defined
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:1492: recipe for target 'libprotobuf-lite.la' failed
| make[3]: *** [libprotobuf-lite.la] Error 1
| make[3]: *** Waiting for unfinished jobs
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/porter/usr/lib/libc_nonshared.a(elf-init.oS):
In function `__libc_csu_init':
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_end'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/glibc/2.22-r0/git/csu/elf-init.c:89:
undefined reference to `__init_array_start'
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
.libs/libprotobuf.so.10.0.0: hidden symbol `__init_array_end' isn't
defined
| 
/mnt/ssd2/yocto/dev/tmp/agl-rcr-wk2/sysroots/x86_64-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/ld:
final link failed: Bad value
| collect2: error: ld returned 1 exit 

Re: [yocto] image-vmdk with genericx86

[Takashi Matsuzawa]

Hello.


Well, the below line actually inheriting image-live.bbclass.  The variable 
values I can see by '-e' option may be the final values, not in the middle of 
parsing.


>IMAGE_TYPE_live = "${@build_live(d)}"
>
>inherit ${IMAGE_TYPE_live}


The solution I came up is, to copy genericx86.conf to 
build/conf/machines/generix86.conf (into local conf file folder) and do 
necessary modification to it.
So that I can cancel whatever IMAGE_FSTYPES value set by x86-base.inc.

____
From: Takashi Matsuzawa
Sent: Friday, July 15, 2016 11:25 AM
To: Maxin B. John
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86


Hello.

Though the build successfully completes, but the image does not boot and I 
believe parameters are not set properly for my image.

What I am trying to do is to build xxx.hdddirect image instead of xxx.hddimg 
for genericx86(, on fido).

As I inspect with '-e' option, I believe, at least the following is wrong.

> # $SYSLINUX_ROOT [3 operations]
> #   set 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-live.bbclass:5
> # "root=/dev/ram0"
> #   set? 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-vmdk.bbclass:4
> # "root=/dev/sda2"
> #   set? /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/> 
> poky/meta/classes/boot-directdisk.bbclass:63
> # "root=/dev/sda2"
> # pre-expansion value:
> #   "root=/dev/ram0"
> SYSLINUX_ROOT="root=/dev/ram0"

I think SYSLINUX_ROOT here is set by image-live.bbclass's value, not by 
boot-directdisk.bbclass's.

I feel this is strange that in my local.conf, I have explicitly removed 'live' 
from IMAGE_FSTYPES and added 'vmdk'.

But, in the above, image-live.bbclass seems to be interpreted and affecting the 
variable expansion.

I think, the following line in image.bbclass is deciding if it reads 
image-live.bbclass or not.

>IMAGE_TYPE_live = "${@build_live(d)}"
>
>inherit ${IMAGE_TYPE_live}

Since IMAGE_TYPE_live is set to '' as follows, I believe image-live.bbclass 
should never interpreted?

> # $IMAGE_TYPE_live
> #   set 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image.bbclass:129
> # "${@build_live(d)}"
> IMAGE_TYPE_live=""

I tried BBMASK'ing image-live.bbclass, but it still seems to be read.

So, I am a bit of stuck here.



From: Takashi Matsuzawa
Sent: Thursday, July 14, 2016 10:06 PM
To: Maxin B. John
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86


Hello

>IMAGE_FSTYPES += "vmdk"

Thank you it worked.
(I should remember  '_append'  applied after all '=' assignments are done.)

After .hdddirect image is successfully created, I am still working on the 
following.

i) image does not boot, maybe its boot device path thing...
ii) hddimage, iso images are also generated.  I may want to disable generation 
of these (and leave images types that I need only), so that bitbake completes 
much earlier.
iii) same can be sade to do_populatesdk it seems to run default.


From: Maxin B. John <maxin.j...@intel.com>
Sent: Thursday, July 14, 2016 12:16 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86

Hi Takashi-san,

On Wed, Jul 13, 2016 at 10:51:34AM +, Takashi Matsuzawa wrote:
>Hello, Yocto.
>
>Should it be possible to simply change image class of genericx86 from 
>.hddimg to .hdddirect?
>
>I have been successfully building genericx86 image (that is image-live.bbclass 
>based), and now trying to build it with directdisk (.hdddirect).
>
>I thought it would be simpler to use pre-existing imageclass, so I tried 
>following after finding image-vmdk.bbclass inherits boot-directdisk.
>
>Currently my build is based on Yocto 1.8 (fido).
>
>
>(in my local.conf)
>
>IMAGE_FSTYPES_remove = " live"
>IMAGE_FSTYPES_append = " vmdk"

Instead of the above two, could you use the following line in local.conf and 
build again ?

IMAGE_FSTYPES += "vmdk"

>But this caused following error.
>
>I am currently looking into the class files to find the cause of error, but 
>anyway, this should work?
>
>
>>ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'vmdk' - possibly invalid 
>>type name or missing support class
>> ERROR: Function failed: do_rootfs
>> ERROR: Logfile of failure stored in:
>>/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/genericx86-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_rootfs.20432
>> ERROR: Task 229
>>(/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb,
>> do_rootfs) failed with exit code '1'


Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image-vmdk with genericx86

[Takashi Matsuzawa]

Hello.

Though the build successfully completes, but the image does not boot and I 
believe parameters are not set properly for my image.

What I am trying to do is to build xxx.hdddirect image instead of xxx.hddimg 
for genericx86(, on fido).

As I inspect with '-e' option, I believe, at least the following is wrong.

> # $SYSLINUX_ROOT [3 operations]
> #   set 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-live.bbclass:5
> # "root=/dev/ram0"
> #   set? 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-vmdk.bbclass:4
> # "root=/dev/sda2"
> #   set? /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/> 
> poky/meta/classes/boot-directdisk.bbclass:63
> # "root=/dev/sda2"
> # pre-expansion value:
> #   "root=/dev/ram0"
> SYSLINUX_ROOT="root=/dev/ram0"

I think SYSLINUX_ROOT here is set by image-live.bbclass's value, not by 
boot-directdisk.bbclass's.

I feel this is strange that in my local.conf, I have explicitly removed 'live' 
from IMAGE_FSTYPES and added 'vmdk'.

But, in the above, image-live.bbclass seems to be interpreted and affecting the 
variable expansion.

I think, the following line in image.bbclass is deciding if it reads 
image-live.bbclass or not.

>IMAGE_TYPE_live = "${@build_live(d)}"
>
>inherit ${IMAGE_TYPE_live}

Since IMAGE_TYPE_live is set to '' as follows, I believe image-live.bbclass 
should never interpreted?

> # $IMAGE_TYPE_live
> #   set 
> /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image.bbclass:129
> # "${@build_live(d)}"
> IMAGE_TYPE_live=""

I tried BBMASK'ing image-live.bbclass, but it still seems to be read.

So, I am a bit of stuck here.



From: Takashi Matsuzawa
Sent: Thursday, July 14, 2016 10:06 PM
To: Maxin B. John
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86


Hello

>IMAGE_FSTYPES += "vmdk"

Thank you it worked.
(I should remember  '_append'  applied after all '=' assignments are done.)

After .hdddirect image is successfully created, I am still working on the 
following.

i) image does not boot, maybe its boot device path thing...
ii) hddimage, iso images are also generated.  I may want to disable generation 
of these (and leave images types that I need only), so that bitbake completes 
much earlier.
iii) same can be sade to do_populatesdk it seems to run default.


From: Maxin B. John <maxin.j...@intel.com>
Sent: Thursday, July 14, 2016 12:16 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86

Hi Takashi-san,

On Wed, Jul 13, 2016 at 10:51:34AM +, Takashi Matsuzawa wrote:
>Hello, Yocto.
>
>Should it be possible to simply change image class of genericx86 from 
>.hddimg to .hdddirect?
>
>I have been successfully building genericx86 image (that is image-live.bbclass 
>based), and now trying to build it with directdisk (.hdddirect).
>
>I thought it would be simpler to use pre-existing imageclass, so I tried 
>following after finding image-vmdk.bbclass inherits boot-directdisk.
>
>Currently my build is based on Yocto 1.8 (fido).
>
>
>(in my local.conf)
>
>IMAGE_FSTYPES_remove = " live"
>IMAGE_FSTYPES_append = " vmdk"

Instead of the above two, could you use the following line in local.conf and 
build again ?

IMAGE_FSTYPES += "vmdk"

>But this caused following error.
>
>I am currently looking into the class files to find the cause of error, but 
>anyway, this should work?
>
>
>>ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'vmdk' - possibly invalid 
>>type name or missing support class
>> ERROR: Function failed: do_rootfs
>> ERROR: Logfile of failure stored in:
>>/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/genericx86-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_rootfs.20432
>> ERROR: Task 229
>>(/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb,
>> do_rootfs) failed with exit code '1'


Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image-vmdk with genericx86

[Takashi Matsuzawa]

Hello

>IMAGE_FSTYPES += "vmdk"

Thank you it worked.
(I should remember  '_append'  applied after all '=' assignments are done.)

After .hdddirect image is successfully created, I am still working on the 
following.

i) image does not boot, maybe its boot device path thing...
ii) hddimage, iso images are also generated.  I may want to disable generation 
of these (and leave images types that I need only), so that bitbake completes 
much earlier.
iii) same can be sade to do_populatesdk it seems to run default.


From: Maxin B. John <maxin.j...@intel.com>
Sent: Thursday, July 14, 2016 12:16 AM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86

Hi Takashi-san,

On Wed, Jul 13, 2016 at 10:51:34AM +, Takashi Matsuzawa wrote:
>Hello, Yocto.
>
>Should it be possible to simply change image class of genericx86 from 
>.hddimg to .hdddirect?
>
>I have been successfully building genericx86 image (that is image-live.bbclass 
>based), and now trying to build it with directdisk (.hdddirect).
>
>I thought it would be simpler to use pre-existing imageclass, so I tried 
>following after finding image-vmdk.bbclass inherits boot-directdisk.
>
>Currently my build is based on Yocto 1.8 (fido).
>
>
>(in my local.conf)
>
>IMAGE_FSTYPES_remove = " live"
>IMAGE_FSTYPES_append = " vmdk"

Instead of the above two, could you use the following line in local.conf and 
build again ?

IMAGE_FSTYPES += "vmdk"

>But this caused following error.
>
>I am currently looking into the class files to find the cause of error, but 
>anyway, this should work?
>
>
>>ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'vmdk' - possibly invalid 
>>type name or missing support class
>> ERROR: Function failed: do_rootfs
>> ERROR: Logfile of failure stored in:
>>/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/genericx86-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_rootfs.20432
>> ERROR: Task 229
>>(/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb,
>> do_rootfs) failed with exit code '1'


Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] image-vmdk with genericx86

[Takashi Matsuzawa]

Hello, Yocto.


Should it be possible to simply change image class of genericx86 from 
.hddimg to .hdddirect?


I have been successfully building genericx86 image (that is image-live.bbclass 
based), and now trying to build it with directdisk (.hdddirect).

I thought it would be simpler to use pre-existing imageclass, so I tried 
following after finding image-vmdk.bbclass inherits boot-directdisk.

Currently my build is based on Yocto 1.8 (fido).


(in my local.conf)

IMAGE_FSTYPES_remove = " live"

IMAGE_FSTYPES_append = " vmdk"

But this caused following error.

I am currently looking into the class files to find the cause of error, but 
anyway, this should work?


>ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'vmdk' - possibly invalid 
>type name or missing support class
> ERROR: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/genericx86-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_rootfs.20432
> ERROR: Task 229
(/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb,
 do_rootfs) failed with exit code '1'

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

Re: [yocto] linux/limits.h: No such file or directory

[Takashi Matsuzawa]

Hello, thank you for your suggestion.

Yes, I was aware of the post, but I was not sure if you came up with a 
workaround..


In fact, my problem was gone once I physically (not by -c cleansstate, 
cleanall, etc.) removed SSTATE_CACHE directory.

(I think bitbake fails in unclear errors if previous build attempts failed or 
interrupted and leaving files in irregular states.)


Building everything from scratch was a pain (more than 1 day for my build 
machines), so if I see the same issue next time, I will try your workaround.



From: Clemens Lang <clemens.l...@bmw-carit.de>
Sent: Thursday, July 7, 2016 4:45 PM
To: Takashi Matsuzawa
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] linux/limits.h: No such file or directory

Hi,

Takashi Matsuzawa <tmatsuz...@uievolution.com> wrote:

> >configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E
> --sysroot=/mnt/ssd2/>yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> " fails sanity check
> >| See `config.log' for more details.
>
> If I look into config.log
> (gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc/config.log)
> as suggested, I can see the following.
> It says linux/limits.h is not found.
>
> (in config.log)
> >usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such
> file or directory

This looks a lot like a problem we've seen a while ago. See
   https://lists.yoctoproject.org/pipermail/yocto/2015-July/025856.html
which is the mailing list post a colleague sent to the list back then.

Looking at our git history, the workaround we did back then was add a
dependency from gcc-crosssdk-initial to nativesdk-linux-libc-headers if
$TARGET_OS starts with "linux".


HTH,
Clemens
--
BMW Car IT GmbH
Clemens Lang
Spezialist Entwicklung
Lise-Meitner-Straße 14
89081 Ulm

Tel: +49-731-37804182
Mail: clemens.l...@bmw-carit.de
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Alexis Trolin
Sitz und Registergericht: München HRB 134810

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

[yocto] linux/limits.h: No such file or directory

[Takashi Matsuzawa]

Hello Yocto.

I am seeing this error recently, and wonder if it is a known issue that has a 
workaround.

It does not go even if I delete DL_DIR or SSTATE_CACHE, etc.  It started to 
happen, though previously the build ran well.

>configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E 
>--sysroot=/mnt/ssd2/>yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
> " fails sanity check
>| See `config.log' for more details.

If I look into config.log 
(gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc/config.log) 
as suggested, I can see the following.
It says linux/limits.h is not found.

(in config.log)
>usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file 
>or directory

I googled some, and found a few similar reports (e.g. install kernel headers 
first, could be a race condition, etc.) but I am not sure practically how to 
avoid this build break.

Error log (on bitable console):


| checking for x86_64-pokysdk-linux-gcc  
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
 option to accept ISO C89... none needed
| checking how to run the C preprocessor... x86_64-pokysdk-linux-gcc -E 
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
| configure: error: in 
`/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/gcc-4.9.2/build.x86_64-pokysdk-linux.x86_64-pokysdk-linux/libgcc':
| configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E 
--sysroot=/mnt/ssd2/yocto/dev/tmp/x86-wk3/sysroots/x86_64-nativesdk-pokysdk-linux
 " fails sanity check
| See `config.log' for more details.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at 
/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/4.9.2-r0/temp/log.do_configure.888)
ERROR: Task 3580 
(virtual:nativesdk:/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-devtools/gcc/libgcc-initial_4.9.bb,
 do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4247 tasks of which 2301 didn't need to be rerun 
and 1 failed.
Waiting for 0 running tasks to finish:



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

Re: [yocto] Shorter build time?

[Takashi Matsuzawa]

By the way, PyPy seems to have some restriction that is not fully compatible 
with CPyhon and bitbake scripts may not run as they are.  I tried it yesterday 
and learned that it is not a simple in-place replacement.



From: Burton, Ross <ross.bur...@intel.com>
Sent: Tuesday, July 5, 2016 3:50 AM
To: Marcelo E. Magallon
Cc: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] Shorter build time?


On 4 July 2016 at 19:10, Marcelo E. Magallon 
<marcelo.magal...@hpe.com<mailto:marcelo.magal...@hpe.com>> wrote:
That is true, but I've seen cases where the start up time of Python (or
the time it takes bitbake to start "doing work") is *perceptually* much
larger than the work done by the recipe, or at least it looks like it
represents a sigficant fraction of the total work. That's where PyPy
might help.

Measuring that overhead should be fairly simple, and if it's true then having a 
pool of workers would be a good optimisation.

Ross

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

Re: [yocto] ICECC build failures?

[Takashi Matsuzawa]

Thank you for your comment.

So they are.  I will try to mask them one by one then.


From: Peter Bergin <peter.ber...@tritech.se>
Sent: Friday, July 1, 2016 1:05 PM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] ICECC build failures?

Hi,

On 07/01/2016 03:18 AM, Takashi Matsuzawa wrote:

Hello Yocto.

Recently I am trying icecc with bitbake and amd halfway satisfied.
Good to see batch of my compilation jobs consumed by my build machines on icemon
is not bad.

However, I can see my builds fail in certain condition eveytime and
wonder if it is a known issue and a workaround exists?

Symptom is the follows.

1) Using x86_64 build host and build machies.  All of them are running
Ubutnu 16.04.
2) My image is based on Fido (18.0).
3) I am just doing INHERIT += "icecc" and the jobs are shared with
build machines correctly.
4) x86 (genericx86) build is OK with and without icecee.
5) imx (sabre6qauto) build is OK without icecc, but NG (fails) with icecc.

The following is the failure log.
It says relocation record error during linkage.  I googled for a while
and learned similar error could be seen if there is binutils (libtool)
version mistmatch.

Maybe a) the host-provided native toolchain and b) yocto-provided
native/cross toolchain have version mismatch?  But I do not see this
error when I am not using icecc.  I just think if it is OK without
icecc, the same should be expected even if I use icecc (it just runs
the same toolchain on different PCs?)


| x86_64-pokysdk-linux-libtool: link: x86_64-pokysdk-linux-gcc
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-shared   .libs/conf.o .libs/confmisc.o .libs/input.o .libs/output.o
.libs/async.o .libs/error.o .libs/dlmisc.o .libs/socket.o
.libs/shmarea.o .libs/userfile.o .libs/names.o   -Wl,--whole-archive
control/.libs/libcontrol.a mixer/.libs/libmixer.a pcm/.libs/libpcm.a
timer/.libs/libtimer.a rawmidi/.libs/librawmidi.a
hwdep/.libs/libhwdep.a seq/.libs/libseq.a ucm/.libs/libucm.a
alisp/.libs/libalisp.a -Wl,--no-whole-archive
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-lm -ldl -lpthread -lrt
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-O2 -Wl,--version-script=Versions -Wl,--no-undefined -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-O1 -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-O1   -Wl,-soname -Wl,libasound.so.2 -o .libs/libasound.so.2.0.0
| 
/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-linux/usr/libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/4.9.2/ld:
.libs/conf.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a shared object; recompile with -fPIC
| .libs/conf.o: error adding symbols: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:484: recipe for target 'libasound.la' failed
| make[2]: *** [libasound.la] Error 1
| make[2]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:538: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:399: recipe for target 'all-recursive' failed
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/temp/log.do_compile.31561)






Some packages does not work with ICECC in a similar way some package do not 
work with PARALLEL_MAKE. You can work with the variable ICECC_USER_PACKAGE_BL 
to disable ICECC compilation for the failing packages.


Best regards,
/Peter<http://www.yoctoproject.org/docs/2.0.2/mega-manual/mega-manual.html#var-ICECC_USER_PACKAGE_BL>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shorter build time?

[Takashi Matsuzawa]

Hmm, thank you for your comments.

So, they may be talking about single-thread nature within a python program, and 
as for bitbake python tasks they should be working in parallel.


There seems to be PyPy, Stackless Python, etc. but I am not sure they can be 
tried 'in-place' to see if they work faster.


From: Daniel. <danielhi...@gmail.com>
Sent: Saturday, July 2, 2016 2:13 AM
To: Burton, Ross
Cc: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] Shorter build time?

So we have full parallelism :)

2016-07-01 14:01 GMT-03:00 Burton, Ross <ross.bur...@intel.com>:
>
> On 1 July 2016 at 17:37, Daniel. <danielhi...@gmail.com> wrote:
>>
>> I read that python can't execute multiple threads simultaneously, but
>> that wouldn't be a problem if each python task is executed at its own
>> interpreter instance (process). This last statement is what I don't
>> really know, some experts on Yocto's internals may clarify that, maybe
>
>
> Yes, each worker is a separate Python process.
>
> Ross



--
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Shorter build time?

[Takashi Matsuzawa]

Hello Yocto.

Well, this may not be a very new topic, but I wonder if you have recent 
suggetions.
So far I have tried the followings and see some improvement, making the build 
time to days to hours.

1) All of the directories, DL_DIR, SSTATE_CACHE, TMPDIR, DEPLOY_DIR are on SSD.
2) .repo and working directory (where I synch my recipes) also on SSD.
3) Set BB_NUMBER_PARSE_THREADS/PARALLEL_MAKE/BB_NUMBER_THREADS to something 
like 20, 30, etc.
4) Enable use of ICECC.
5) Use pigz, pbzip2, pxz instead of gzip, bzip2 and xz.

I can see with 3-5), I am benefited from my multicore PCs and see some scaling 
effects (if I can add more PCs or CPU core.)
However I think there is i the build not paralleled or distributed easily.

i) python tasks
They say python has slimitation of being single thread, and could be a bottle 
neck since most of yocto build tasks are in python, if not native/cross 
toolchain jobs.

ii) zip / tar tasks
e.g. seeing rootfs taking forever, jobs not distributed to the other machines.
I understand it is writing files to one target tree and doing a bit tar/zip for 
the files, being one big job though.

I wonder if I can do anything with i) and ii) at least to make them processed 
in parallel.
ICECC only can dispatch gcc jobs I believe.
Any previous attemps to do the similar to non-gcc jobs?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ICECC build failures?

[Takashi Matsuzawa]

Hello Yocto.

Recently I am trying icecc with bitbake and amd halfway satisfied.
Good to see batch of my compilation jobs consumed by my build machines on icemon
is not bad.

However, I can see my builds fail in certain condition eveytime and
wonder if it is a known issue and a workaround exists?

Symptom is the follows.

1) Using x86_64 build host and build machies.  All of them are running
Ubutnu 16.04.
2) My image is based on Fido (18.0).
3) I am just doing INHERIT += "icecc" and the jobs are shared with
build machines correctly.
4) x86 (genericx86) build is OK with and without icecee.
5) imx (sabre6qauto) build is OK without icecc, but NG (fails) with icecc.

The following is the failure log.
It says relocation record error during linkage.  I googled for a while
and learned similar error could be seen if there is binutils (libtool)
version mistmatch.

Maybe a) the host-provided native toolchain and b) yocto-provided
native/cross toolchain have version mismatch?  But I do not see this
error when I am not using icecc.  I just think if it is OK without
icecc, the same should be expected even if I use icecc (it just runs
the same toolchain on different PCs?)


| x86_64-pokysdk-linux-libtool: link: x86_64-pokysdk-linux-gcc
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-shared   .libs/conf.o .libs/confmisc.o .libs/input.o .libs/output.o
.libs/async.o .libs/error.o .libs/dlmisc.o .libs/socket.o
.libs/shmarea.o .libs/userfile.o .libs/names.o   -Wl,--whole-archive
control/.libs/libcontrol.a mixer/.libs/libmixer.a pcm/.libs/libpcm.a
timer/.libs/libtimer.a rawmidi/.libs/librawmidi.a
hwdep/.libs/libhwdep.a seq/.libs/libseq.a ucm/.libs/libucm.a
alisp/.libs/libalisp.a -Wl,--no-whole-archive
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-lm -ldl -lpthread -lrt
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-O2 -Wl,--version-script=Versions -Wl,--no-undefined -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-O1 -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-O1   -Wl,-soname -Wl,libasound.so.2 -o .libs/libasound.so.2.0.0
| 
/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-linux/usr/libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/4.9.2/ld:
.libs/conf.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a shared object; recompile with -fPIC
| .libs/conf.o: error adding symbols: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:484: recipe for target 'libasound.la' failed
| make[2]: *** [libasound.la] Error 1
| make[2]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:538: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:399: recipe for target 'all-recursive' failed
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/temp/log.do_compile.31561)




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

[yocto] Cannot create symlink to 'x86_64-pokysdk-linux' error

[Takashi Matsuzawa]

Hello yocto.
I have been successfully building several yocto based target trees,
but now trying qemux86-64 build and it is causing error.  Familiar
with the below sympthom and maybe you have any suggestion?

I think this begain happening when I did -c populate_sdk, but not sure.
The other targets (including qemux86) is building fine.  I am now
re-building it again after removing downloads, sstate-cache, tmp, etc.


ERROR: Error executing a python function in
/home/tmatsuzawa/wk/yocto_x64/wk1/build-root/poky/meta/recipes-devtools/gcc/libgcc_5.2.bb:

...
Exception: CalledProcessError: Command 'cd
/mnt/sdb1/yocto/dev/tmp/yocto_x64-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc/5.2.0-r0/sysroot-destdir;
find . -type d -print | tar -cf - -C
/mnt/sdb1/yocto/dev/tmp/yocto_x64-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc/5.2.0-r0/sysroot-destdir
-p --files-from - --no-recursion | tar -xf - -C
/mnt/sdb1/yocto/dev/tmp/yocto_x64-wk1/sysroots/x86_64-nativesdk-pokysdk-linux'
returned non-zero exit status 2 with output tar:
./opt/poky-agl/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/x86_64-poky-linux:
Cannot create symlink to 'x86_64-pokysdk-linux': File exists
tar: 
./opt/poky-agl/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/x86_64-poky-linux:
Cannot create symlink to 'x86_64-pokysdk-linux': File exists
...


I think this is copying files using tar as follows, and in the
copeid-to directory there is already 'x86_64-pokysdk-linux' directory
whereas in copied-from directory it is a symbolic link.  Hence tar
fails.

(coppied-from)
${TMPDIR}/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc/5.2.0-r0/sysroot-destdir
x86_64-poky-linux -> x86_64-pokysdk-linux (symlink)
x86_64-pokysdk-linux (directory)

=>

(copied-to)
${TMPDIR}/sysroots/x86_64-nativesdk-pokysdk-linux
x86_64-poky-linux (directory)
x86_64-pokysdk-linux (directory)

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