[yocto] error: impossible constraint in 'asm'

[dhkoo]

Hi.

 

Recently, I'm work on mplayer that media player for my custom system.

My Kernel version is 3.8, and mplayer version is 1.3.0.

 

And when I perform bitbake, there's error on do_compile process. The
messages says like below.

ERROR: mplayer-1.3.0-r0 do_compile: oe_runmake failed

ERROR: mplayer-1.3.0-r0 do_compile: Function failed: do_compile (log file is
located at
/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mplayer/1.3.0-
r0/temp/log.do_compile.2960)

ERROR: Logfile of failure stored in:
/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mplayer/1.3.0-
r0/temp/log.do_compile.2960

Log data follows:

| DEBUG: Executing shell function do_compile

| NOTE: make -j 4

| ./codec-cfg etc/codecs.conf > codecs.conf.h

| arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=vfp
-mfloat-abi=hard
--sysroot=/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mpla
yer/1.3.0-r0/recipe-sysroot -MMD -MP -Wundef  -Wstrict-prototypes
-Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99  -D_POSIX_C_SOURCE=200112
-D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg  -fexpensive-optimizations
-fomit-frame-pointer -frename-registers -O4 -ffast-math -fno-tree-vectorize
-fno-asynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -mcpu=cortex-a9 -mfpu=neon   -D_REENTRANT -DZLIB_CONST
-c -o cpudetect.o cpudetect.c

| arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=vfp
-mfloat-abi=hard
--sysroot=/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mpla
yer/1.3.0-r0/recipe-sysroot -MMD -MP -Wundef  -Wstrict-prototypes
-Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99  -D_POSIX_C_SOURCE=200112
-D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg  -fexpensive-optimizations
-fomit-frame-pointer -frename-registers -O4 -ffast-math -fno-tree-vectorize
-fno-asynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -mcpu=cortex-a9 -mfpu=neon   -D_REENTRANT -DZLIB_CONST
-c -o edl.o edl.c

| arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=vfp
-mfloat-abi=hard
--sysroot=/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mpla
yer/1.3.0-r0/recipe-sysroot -MMD -MP -Wundef  -Wstrict-prototypes
-Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99  -D_POSIX_C_SOURCE=200112
-D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg  -fexpensive-optimizations
-fomit-frame-pointer -frename-registers -O4 -ffast-math -fno-tree-vectorize
-fno-asynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -mcpu=cortex-a9 -mfpu=neon   -D_REENTRANT -DZLIB_CONST
-c -o fmt-conversion.o fmt-conversion.c

| Reading optional codecs config file etc/codecs.conf: 224 audio & 451 video
codecs

| arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=vfp
-mfloat-abi=hard
--sysroot=/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mpla
yer/1.3.0-r0/recipe-sysroot -MMD -MP -Wundef  -Wstrict-prototypes
-Wmissing-prototypes -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99  -D_POSIX_C_SOURCE=200112
-D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE -I. -Iffmpeg  -fexpensive-optimizations
-fomit-frame-pointer -frename-registers -O4 -ffast-math -fno-tree-vectorize
-fno-asynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -mcpu=cortex-a9 -mfpu=neon   -D_REENTRANT -DZLIB_CONST
-c -o m_config.o m_config.c

| m_config.c: In function 'm_config_add_option':

| m_config.c:326:14: warning: assignment discards 'const' qualifier from
pointer target type [-Wdiscarded-qualifiers]

|  co->name = arg->name;

|   ^

| cpudetect.c: In function 'do_cpuid':

| cpudetect.c:258:5: error: impossible constraint in 'asm'

|  __asm__ volatile

|  ^~~

| Makefile:726: recipe for target 'cpudetect.o' failed

| make: *** [cpudetect.o] Error 1

| make: *** Waiting for unfinished jobs

| ERROR: oe_runmake failed

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_compile (log file is located at
/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mplayer/1.3.0-
r0/temp/log.do_compile.2960)

ERROR: Task
(/home/ku/yocto/meta-top/recipes-top/mplayer/mplayer_1.3.0.bb:do_compile)
failed with exit code '1'

NOTE: Tasks Summary: Attempted 1475 tasks of which 1474 didn't need to be
rerun and 1 failed.

 

Does anyone has an idea??

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

Re: [yocto] error: impossible constraint in 'asm'

[philippe gislard]

2018-02-01 9:32 GMT+01:00 dhkoo :
> Hi.
>
>
>
> Recently, I'm work on mplayer that media player for my custom system.
>
> My Kernel version is 3.8, and mplayer version is 1.3.0.
>
>
>
> And when I perform bitbake, there's error on do_compile process. The
> messages says like below.
>
> [...]
>
> | arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm -mfpu=vfp
> -mfloat-abi=hard
> --sysroot=/home/ku/yocto/build/tmp/work/armv7ahf-vfp-poky-linux-gnueabi/mplayer/1.3.0-r0/recipe-sysroot
> -MMD -MP -Wundef  -Wstrict-prototypes -Wmissing-prototypes
> -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement
> -std=gnu99  -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_ISOC99_SOURCE
> -I. -Iffmpeg  -fexpensive-optimizations -fomit-frame-pointer
> -frename-registers -O4 -ffast-math -fno-tree-vectorize
> -fno-asynchronous-unwind-tables -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE64_SOURCE -mcpu=cortex-a9 -mfpu=neon   -D_REENTRANT -DZLIB_CONST
> -c -o m_config.o m_config.c
>
> | m_config.c: In function 'm_config_add_option':
>
> | m_config.c:326:14: warning: assignment discards 'const' qualifier from
> pointer target type [-Wdiscarded-qualifiers]
>
> |  co->name = arg->name;
>
> |   ^
>
> | cpudetect.c: In function 'do_cpuid':
>
> | cpudetect.c:258:5: error: impossible constraint in 'asm'
>
> |  __asm__ volatile
>
> |  ^~~
>
> [...]
>

Hi dhkoo,

I'm not sure, but the cpudetect.c file from the official website
should be preprocessed so that all it's content is not compile when
using ARCH_ARM.
All the code from the file is included in a
#if ARCH_X86
preprocessor statement

Regarding the line 258:
It's using embedded assembly code which I understand is specific for
the X86 architecture.

Hope this helps.


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

[yocto] meta-ide-support toolchain & Recipe-specific Sysroots

[Mircea Gliga]

I have a problem starting from the rocko upgrade and related to the 
Recipe-specific Sysroots introduced in Yocto 2.3


Our project uses cmake. So out recipe has:
DEPENDS = "cmake-native [...]"

So cmake ends up in 
build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/component/1.0-r0/recipe-sysroot-native/usr/bin/cmake

So when building inside yocto everything is ok.

When we build outside yocto, we use the cross-toolchain generated and 
populated within the Build Directory:

  $ bitbake meta-ide-toolchain
and then source the environment:
  $ source build/tmp/environment-setup-cortexa5hf-neon-poky-linux-gnueabi

On rocko OECORE_NATIVE_SYSROOT is set to 
[...]/build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/meta-ide-support/1.0-r3/recipe-sysroot-native 
- which doesn't have cmake:

  $ which cmake
  $ /no cmake found/

And on Krogoth it was build/tmp/sysroots/x86_64-linux - cmake is there:
  $ which cmake
  /build/tmp/sysroots/x86_64-linux/usr/bin/cmake


How can I add it to my toolchain so that I can also build outside yocto ?

Thanks in advance !

Regards

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

Re: [yocto] [meta-raspberrypi][PATCH] [kronos]wayland lib linking added for libbrcmEGL to avoid undefined symbol while linking libbrcmEGL.so

[Andrei Gherzan]

On Thu, Feb 1, 2018 at 6:56 AM, HASEENAMOL 
wrote:

> [meta-raspberrypi][PATCH]
>
> In wayland enabled build libbrcmEGL lib is using wayland functions, but
> during the build it is not linking with wayland libraries. Hence if try to
> link libbrcmEGL, will get undefined symbols.
>
>
>
> Best Regards
>
> Haseenamol
>

Hi,

Thanks for your contribution. We are currently using github for sending
patches to this yocto BSP. See
http://meta-raspberrypi.readthedocs.io/en/latest/contributing.html for more
information.

Regards,

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

[yocto] Patching only the target version of a package?

[Michael Habibi]

I'm sure this is really simple but I haven't quite wrapped my head around
it.

We have a bbappend file that supplies a set of patches. It currently has
the unintended side-effect of patching both the native version used during
the Yocto build process, and the eventual target version. How do I modify
the recipe such that it only acts upon the target version?

Would it be something like recipe-cross.bbappend instead of
recipe.bbappend? Or something similar?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patching only the target version of a package?

[Burton, Ross]

On 1 February 2018 at 14:29, Michael Habibi  wrote:

> I'm sure this is really simple but I haven't quite wrapped my head around
> it.
>
> We have a bbappend file that supplies a set of patches. It currently has
> the unintended side-effect of patching both the native version used during
> the Yocto build process, and the eventual target version. How do I modify
> the recipe such that it only acts upon the target version?
>
> Would it be something like recipe-cross.bbappend instead of
> recipe.bbappend? Or something similar?
>


SRC_URI_append_class-target = " file://..."

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

Re: [yocto] Patching only the target version of a package?

[Michael Habibi]

So let's say my whole bbappend file is only necessary for the target
version. Can I rename the whole thing package-target.bbappend (add the
-target suffix) and it will only append it to the recipe when building the
target? Is "target" the actual suffix or is it a placeholder for something
more specific? I have only seen -native, -cross, and some other ones that
don't seem to apply to this case.

On Thu, Feb 1, 2018 at 8:44 AM, Burton, Ross  wrote:

> On 1 February 2018 at 14:29, Michael Habibi  wrote:
>
>> I'm sure this is really simple but I haven't quite wrapped my head around
>> it.
>>
>> We have a bbappend file that supplies a set of patches. It currently has
>> the unintended side-effect of patching both the native version used during
>> the Yocto build process, and the eventual target version. How do I modify
>> the recipe such that it only acts upon the target version?
>>
>> Would it be something like recipe-cross.bbappend instead of
>> recipe.bbappend? Or something similar?
>>
>
>
> SRC_URI_append_class-target = " file://..."
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patching only the target version of a package?

[Burton, Ross]

On 1 February 2018 at 15:03, Michael Habibi  wrote:

> So let's say my whole bbappend file is only necessary for the target
> version. Can I rename the whole thing package-target.bbappend (add the
> -target suffix) and it will only append it to the recipe when building the
> target? Is "target" the actual suffix or is it a placeholder for something
> more specific? I have only seen -native, -cross, and some other ones that
> don't seem to apply to this case.
>
>
That won't work, as native and cross suffixes in recipes are for humans,
not bitbake.

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

[yocto] fsck fsck.ext4 no such file or directory

[Thibaut SARRAZIN]

Hi all,

when I try to use fsck tool, this one answer me,  fsck : fsck.ext4 no 
such file or directory. anyone have an idea whyt these files are not 
include automatically in the rootfs?



Thanks

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

[yocto] [multilib] 64-bit and 32-bit package install the same executable

[Aaron_Wright]

I've noticed that for my custom image both the 32-bit and the 64-bit 
versions of the same package are getting installed. For example, it has 
both shadow-base and lib32-shadow-base installed. When I check the 
/bin/su.shadow executable I find it is 32-bit.

Is it expected that the lib32 version of the package will "win" when both 
packages install the same /bin/su.shadow file?

Is this something that is always true, so that I can always assume, when 
two packages install the same executable, that it will end up being 
32-bit?

Why does the packaging system, PACKAGE_CLASSES = "package_ipk", not give 
an error when both packages install the same file?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] opkg-build: improve package reproducibility

[Alejandro del Castillo]

merged


From: Alejandro del Castillo 
Sent: Monday, January 29, 2018 4:23:15 AM
To: opkg-de...@googlegroups.com; yocto@yoctoproject.org
Cc: Alejandro del Castillo
Subject: [PATCH] opkg-build: improve package reproducibility

Implements some of the recommendations by reproducible-build.org [1]

- Set modification time to SOURCE_DATE_EPOCH env variable
- Enable deterministic sorting of directory entries
- Do not save timestamp on gzip compressed archive

bugzilla #11242

[1] https://reproducible-builds.org/docs/archives/

Signed-off-by: Alejandro del Castillo 
---
 opkg-build | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/opkg-build b/opkg-build
index 0fe513a..7bfdd99 100755
--- a/opkg-build
+++ b/opkg-build
@@ -149,6 +149,7 @@ outer=ar
 noclean=0
 opkext=0
 compressor=gzip
+compressorargs="-9n"

 # Determine if tar supports the --format argument by checking the help output.
 #
@@ -222,6 +223,15 @@ done

 cext=$(compressor_ext $compressor)

+if [ $compressor = "gzip" ] ; then
+   # pgzip requires -T to avoid timestamps on the gzip archive
+   if gzip --help 2>&1 | grep -- "-T" > /dev/null; then
+   compressorargs="-9nT"
+   fi
+else
+   compressorargs=""
+fi
+
 shift $(($OPTIND - 1))

 # continue on to process additional arguments
@@ -267,9 +277,11 @@ fi
 tmp_dir=$dest_dir/IPKG_BUILD.$$
 mkdir $tmp_dir

+build_date="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" 
+%Y-%m-%d)"
+
 echo $CONTROL > $tmp_dir/tarX
-( cd $pkg_dir && tar $ogargs -X $tmp_dir/tarX -c --$compressor $tarformat -f 
$tmp_dir/data.tar.$cext . )
-( cd $pkg_dir/$CONTROL && tar $ogargs -cz $tarformat -f 
$tmp_dir/control.tar.gz . )
+( cd $pkg_dir && tar $ogargs --sort=name --mtime=$build_date -X $tmp_dir/tarX 
-c $tarformat . | $compressor $compressorargs > $tmp_dir/data.tar.$cext )
+( cd $pkg_dir/$CONTROL && tar $ogargs --sort=name --mtime=$build_date -c 
$tarformat . | gzip $compressorargs > $tmp_dir/control.tar.gz )
 rm $tmp_dir/tarX

 echo "2.0" > $tmp_dir/debian-binary
@@ -284,7 +296,7 @@ rm -f $pkg_file
 if [ "$outer" = "ar" ] ; then
   ( cd $tmp_dir && ar -crf $pkg_file ./debian-binary ./control.tar.gz 
./data.tar.$cext )
 else
-  ( cd $tmp_dir && tar -cz $tarformat -f $pkg_file ./debian-binary 
./control.tar.gz ./data.tar.$cext )
+  ( cd $tmp_dir && tar -c --sort=name --mtime=$build_date $tarformat 
./debian-binary ./control.tar.gz ./data.tar.$cext | gzip $compressorargs > 
$pkg_file )
 fi

 rm $tmp_dir/debian-binary $tmp_dir/data.tar.$cext $tmp_dir/control.tar.gz
--
2.15.1

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

Re: [yocto] Patching only the target version of a package?

[Michael Habibi]

Thanks, that seems to be pretty much precisely what I need. Where can I
learn more about the class construct, e.g. class-target and native? I saw
some references to it in the docs, but not an actual explanation of how
that all works and is put together. Any ideas?

On Thu, Feb 1, 2018 at 9:34 AM, Burton, Ross  wrote:

> On 1 February 2018 at 15:03, Michael Habibi  wrote:
>
>> So let's say my whole bbappend file is only necessary for the target
>> version. Can I rename the whole thing package-target.bbappend (add the
>> -target suffix) and it will only append it to the recipe when building the
>> target? Is "target" the actual suffix or is it a placeholder for something
>> more specific? I have only seen -native, -cross, and some other ones that
>> don't seem to apply to this case.
>>
>>
> That won't work, as native and cross suffixes in recipes are for humans,
> not bitbake.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing Wind River Linux

[Mark Hatle]

On 1/30/18 3:15 AM, 永瀨桂 wrote:
> Hi,
> I'm trying to build the installer for using the WindRiverLinux9 with a  
> development board.
> 
> I want to build the installer's image using the Intel-corei7-64 BSP, but  
> I can't build wrlinux-image-glibc-small like in the guide below.
> https://knowledge.windriver.com/en-us/000_Products/000/010/050/040/000_Wind_River_Linux_Platform_Developer's_Guide%2C_9/0A0/020/020
> 

The question is specific to Wind River Linux, which is derived from the Yocto
Project, but is not the Yocto Project.

I'll respond in a separate email.

--Mark

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

Re: [yocto] Patching only the target version of a package?

[Burton, Ross]

bbclasses can cause a recipe to be cloned and overrides created.  The
overrides are class-target for the target build, class-native for the
native build, class-nativesdk for the SDK build.

The mechanism is normally inheriting the class directly (eg when a recipe
is only useful as native) or using BBCLASSEXTEND to make it happen
automatically.

Ross

On 1 February 2018 at 19:05, Michael Habibi  wrote:

> Thanks, that seems to be pretty much precisely what I need. Where can I
> learn more about the class construct, e.g. class-target and native? I saw
> some references to it in the docs, but not an actual explanation of how
> that all works and is put together. Any ideas?
>
> On Thu, Feb 1, 2018 at 9:34 AM, Burton, Ross 
> wrote:
>
>> On 1 February 2018 at 15:03, Michael Habibi  wrote:
>>
>>> So let's say my whole bbappend file is only necessary for the target
>>> version. Can I rename the whole thing package-target.bbappend (add the
>>> -target suffix) and it will only append it to the recipe when building the
>>> target? Is "target" the actual suffix or is it a placeholder for something
>>> more specific? I have only seen -native, -cross, and some other ones that
>>> don't seem to apply to this case.
>>>
>>>
>> That won't work, as native and cross suffixes in recipes are for humans,
>> not bitbake.
>>
>> Ross
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] applying patches depending on the image's name

[Martin Vuille]

Hi Ross,

This "two different kernels" feature would be useful to me.

Where can I find out how to use it?

Regards,
MV

On 01/11/18 12:34, Burton, Ross wrote:

No, because images are built from packages, and the packages have already
been built by the time the image is considered.

Using master you can build two different kernels in the same build and have
different kernels in different images.

Ross

On 9 January 2018 at 15:54, Vadim Intelegator <
v.intelega...@sirinsoftware.com> wrote:


Hello,

I have several images (image-a.bb and image-b.bb) in a yocto layer and
want to apply different patches to the kernel depending on the current
image name.
How can that be done?

Thank you in advance.

--
Vadim

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







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

Re: [yocto] gcc leak-sanitizer on arm target

[Pieter Cardoen]

On Wed, Jan 31, 2018 at 7:06 AM, Pieter Cardoen
 wrote:
> > Dear
> >
> > I am having trouble to enable leak sanitizer and thread sanitizer for my 
> > arm target. If I enable gcc-sanitizers, I only have these libraries on the 
> > target rootfs:
> > * libasan.so.3
> > * libasan.so.3.0.0
> > * libsanitizer.spec
> > * libubsan.so.0
> > * libubsan.so.0.0.0
> >
> > liblsan.so.* and libtsan.so.* is missing.
> >
> > I took a look into the build directory:
> > tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gcc-sanitizers/6.2.0-r0/gcc-6.2.0/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/libsanitizer/
> >
> > in file asan/Makefile, I find "toolexeclib_LTLIBRARIES = libasan.la"
> > while in file lsan/Makefiel, it is commented out: "#toolexeclib_LTLIBRARIES 
> > = liblsan.la"
> >
> > Is it possible to compile the leak and thread sanitizer library for arm?
> >
>
> it was only tested on x86  in past so its not included in other
> arches. You can however try it out
> by adding
>
> IMAGE_INSTALL_append = " liblsan libtsan"
>
> to local.conf and if it works report back and we might cook a final
> patch to enable it unconditionally.

Unfortunately, it is not working. Apparently, packages are empty:

ERROR: core-image-cosamira-llc-1.0-r0 do_rootfs: liblsan not found in the feeds 
(cosamira_picozed_zynq7 cortexa9t2hf-neon cortexa9t2hf-vfp cortexa9hf-neon 
cortexa9hf-vfp armv7at2hf-neon armv7ahf-neon armv7at2hf-vfp armv7ahf-vfp 
armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-vfp armv5hf-vfp 
noarch any all) in 
/home/pic/Documents/Builds/YOCTO/Cosamira/yoctobuild/cosamira-picozed-zynq7/tmp/deploy/rpm.
ERROR: core-image-cosamira-llc-1.0-r0 do_rootfs: This is often caused by an 
empty package declared in a recipe's PACKAGES variable. (Empty packages are not 
constructed unless ALLOW_EMPTY_ = '1' is used.)
ERROR: core-image-cosamira-llc-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/pic/Documents/Builds/YOCTO/Cosamira/yoctobuild/cosamira-picozed-zynq7/tmp/work/cosamira_picozed_zynq7-poky-linux-gnueabi/core-image-cosamira-llc/1.0-r0/temp/log.do_rootfs.21151
ERROR: Task 
(/home/pic/Documents/Builds/YOCTO/Cosamira/yoctobuild/sources/meta-tra-mec/recipes-core/images/core-image-cosamira-llc.bb:do_rootfs)
 failed with exit code '1'

>
> > Thanks
> > Pieter
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.


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