Hi Paul ,
Thanks for your answer. Martin pointed me to a patch I will try later on.
I changed the subject
My versions:
* openembedded-core:
commit e848484989307ae6826ba0f5217f7702322181e3
Author: Paul Eggleton <paul.eggle...@linux.intel.com>
Date: Wed Feb 18 10:23:42 2015 +0000
lib/oe/package_manager: support exclusion from complementary glob process
by regex
Sometimes you do not want certain packages to be installed when
installing complementary packages, e.g. when using dev-pkgs in
IMAGE_FEATURES you may not want to install all packages from a
particular multilib. This introduces a new PACKAGE_EXCLUDE_COMPLEMENTARY
variable to allow specifying regexes to match packages to exclude.
(From OE-Core master rev: d4fe8f639d87d5ff35e50d07d41d0c1e9f12c4e3)
Signed-off-by: Paul Eggleton <paul.eggle...@linux.intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.f...@intel.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
* meta-openembedded:
commit 853dcfa0d618dc26bd27b3a1b49494b98d6eee97
Author: Steffen Sledz <sl...@dresearch-fe.de>
Date: Mon Feb 16 19:37:34 2015 +0100
rsyslog: fix name of syslogd ua group
All the other syslogd implementations use 'syslogd' as update alternatives
group name. So rsyslogd should use this too.
Signed-off-by: Steffen Sledz <sl...@dresearch-fe.de>
Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
My situation is I have two machines:
* machineA
* machineB: inherits from machine B (only PREFERRED_VERSION for libxml2 added)
two images:
* imageA
* imageB: inherits from image A
I have one build directory for each machine:
* build-machineA
* build-machineB (only new packages added), two of the package are shared
libraries : libA and libB. libA is linked to libB. libB depends on libA. libA
and libB are cmake recipes
First I build the imageA in build-machineA for machineA
In the build-machineB directory I build imageB for machineB. Moreover I point
SSTATE_DIR or SSTATE_MIRRORS of build-machineB/conf/local.conf to
build-machineA's sstate-cache directory.
libA is built with success but libB's do_compile fails:
/.../build-machineB$ bitbake libB
[...]
/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/arm-opensdk-linux-gnueabi-gcc
-fPIC -g -O2 -W -Werror -Wall -Wextra -Wuninitialized -Wstrict-prototypes
-Wcast-align -Wmissing-prototypes -Wchar-subscripts -Wpointer-arith -Winline
-Wno-conversion -Wshadow -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-shared -Wl,-soname,libsys.so.1 -o libsys.so.1 CMakeFiles/sys.dir/src/crc.c.o
CMakeFiles/sys.dir/src/fast_32k_utils.c.o CMakeFiles/sys.dir/src/filemap.c.o
CMakeFiles/sys.dir/src/hash_tables.c.o CMakeFiles/sys.dir/src/hash_tables_2.c.o
CMakeFiles/sys.dir/src/ipcs_keys.c.o CMakeFiles/sys.dir/src/log.c.o
CMakeFiles/sys.dir/src/MM.c.o CMakeFiles/sys.dir/src/MM_no_mutex.c.o
CMakeFiles/sys.dir/src/random.c.o CMakeFiles/sys.dir/src/registry.c.o
CMakeFiles/sys.dir/src/time.c.o CMakeFiles/sys.dir/src/watchdog_timer.c.o
CMakeFiles/sys.dir/src/watchdog_client.c.o
CMakeFiles/sys.dir/src/watchdog_server.c.o
CMakeFiles/sys.dir/src/state_machine.c.o
CMakeFiles/sys.dir/src/thread_manager.c.o
CMakeFiles/sys.dir/src/sg_log_eina.c.o -lpthread -leina -lpthread -leina
/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/../../libexec/arm-opensdk-linux-gnueabi/gcc/arm-opensdk-linux-gnueabi/4.9.1/ld:
cannot find -llibA
collect2: error:
ld returned 1 exit status
ERROR: Function
failed: do_compile (log file is located at
/.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/temp/log.do_compile.2284)
At this moment I had to find why ld cannot find libA.so in sysroots so I
launched a devshell on libB. In the devshell I cd-ed to the B dir of libB and
run the cross-gcc command with the verbose "-v" option.
/.../build-machineB$
bitbake libB -c devshell
[devshell]
/.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/git
$ cd ../build
[devshell]
/.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/build$
/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/arm-opensdk-linux-gnueabi-gcc
-fPIC -g -O2 -W -Werror -Wall -Wextra -Wuninitialized -Wstrict-prototypes
-Wcast-align -Wmissing-prototypes -Wchar-subscripts -Wpointer-arith -Winline
-Wno-conversion -Wshadow -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-shared -Wl,-soname,libsys.so.1 -o libsys.so.1 CMakeFiles/sys.dir/src/crc.c.o
CMakeFiles/sys.dir/src/fast_32k_utils.c.o CMakeFiles/sys.dir/src/filemap.c.o
CMakeFiles/sys.dir/src/hash_tables.c.o CMakeFiles/sys.dir/src/hash_tables_2.c.o
CMakeFiles/sys.dir/src/ipcs_keys.c.o CMakeFiles/sys.dir/src/log.c.o
CMakeFiles/sys.dir/src/MM.c.o CMakeFiles/sys.dir/src/MM_no_mutex.c.o
CMakeFiles/sys.dir/src/random.c.o CMakeFiles/sys.dir/src/registry.c.o
CMakeFiles/sys.dir/src/time.c.o CMakeFiles/sys.dir/src/watchdog_timer.c.o
CMakeFiles/sys.dir/src/watchdog_client.c.o
CMakeFiles/sys.dir/src/watchdog_server.c.o
CMakeFiles/sys.dir/src/state_machine.c.o
CMakeFiles/sys.dir/src/thread_manager.c.o
CMakeFiles/sys.dir/src/sg_log_eina.c.o -lpthread -leina -lpthread -leina
/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/../../libexec/arm-opensdk-linux-gnueabi/gcc/arm-opensdk-linux-gnueabi/4.9.1/ld:
cannot find –leina –v
I will only show you the interesting part of the
result.
[...]
LIBRARY_PATH=/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/../../lib/arm-opensdk-linux-gnueabi/gcc/arm-opensdk-linux-gnueabi/4.9.1/:/.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/../../lib/arm-opensdk-linux-gnueabi/gcc/:/.../build-machineA/tmp-glibc/sysroots/machineA/lib/:/.../build-machineA/tmp-glibc/sysroots/machineA/usr/lib/arm-opensdk-linux-gnueabi/4.9.1//.../build-machineA/tmp-glibc/sysroots/machineA/usr/lib/
[...]
The symptom is here. Instead of
‘/.../build-machineA/tmp-glibc/sysroots/machineA/usr/lib/’ it should be
‘/.../build-machineB//tmp-glibc/sysroots/machineB/usr/lib/’
I couldn’t find
in libB’s recipe (and included bbclasses) where LIBRARY_PATH is set so I guess
it comes from elswhere.
My guess is that
there is a problem in cross-gcc recipe and somewhere the
<sysroots-target>/usr/lib path is hardcoded in sstate-cache. When
recompilling for a different build bitbake use this cache that is polluted by
this hardcoded path.
Note: I have the
same problem if I do same build type (machine, builddir name) but different
locations.
The meta layer of machineB/imageB has a override of gcc 4.9 which consists only
on:
EXTRA_OECONF_GCC_FLOAT = "${@get_gcc_float_setting(bb, d)}"
I had some problem two while changing the version the PREFERRED_VERSION of a
recipe in local.conf. When recompiling bitbake don't redo do_unpack so
configure/compile/install, one of them fails to find file in S directory. I had
to run cleanall on this package before doing a full bitbake.
I hop I have been clear in my explanation of the situation.
Kind Regards,
--
Jérôme OLIVIER
TEL : +337 52 46 29 25
@ : jerome.oliv...@outlook.com
> From: paul.eggle...@linux.intel.com
> To: jerome.oliv...@outlook.com
> CC: yocto@yoctoproject.org
> Subject: Re: [yocto] Disable sstate-cache for one recipe
> Date: Mon, 19 Oct 2015 12:21:48 +0100
>
> Hi Jérôme,
>
> On Monday 19 October 2015 10:18:41 Jérôme OLIVIER wrote:
> > I use yocto 1.7.2. I have some problem with sstate-cache.
> > I would like to disable totally sstate_cache for only one recipe. Is that
> > possible?
>
> Not really I'm afraid - what is the problem you are experiencing?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
