* Disable sstate-cache for one recipe @ 2015-10-19 10:18 Jérôme OLIVIER 2015-10-19 11:21 ` Paul Eggleton 2015-10-19 12:12 ` Disable sstate-cache for one recipe Martin Jansa 0 siblings, 2 replies; 6+ messages in thread From: Jérôme OLIVIER @ 2015-10-19 10:18 UTC (permalink / raw) To: yocto@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 263 bytes --] Hi everyone, 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? Thank you, -- Jérôme OLIVIER TEL : +337 52 46 29 25 @ : jerome.olivier@outlook.com [-- Attachment #2: Type: text/html, Size: 500 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Disable sstate-cache for one recipe 2015-10-19 10:18 Disable sstate-cache for one recipe Jérôme OLIVIER @ 2015-10-19 11:21 ` Paul Eggleton 2015-10-21 12:10 ` gcc LIBRARY_PATH sstate-cache issue Jérôme OLIVIER 2015-10-19 12:12 ` Disable sstate-cache for one recipe Martin Jansa 1 sibling, 1 reply; 6+ messages in thread From: Paul Eggleton @ 2015-10-19 11:21 UTC (permalink / raw) To: Jérôme OLIVIER; +Cc: yocto 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* gcc LIBRARY_PATH sstate-cache issue 2015-10-19 11:21 ` Paul Eggleton @ 2015-10-21 12:10 ` Jérôme OLIVIER 2015-10-21 20:58 ` Andre McCurdy 0 siblings, 1 reply; 6+ messages in thread From: Jérôme OLIVIER @ 2015-10-21 12:10 UTC (permalink / raw) To: Paul Eggleton; +Cc: yocto@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 8091 bytes --] 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.eggleton@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.eggleton@linux.intel.com> Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> * meta-openembedded: commit 853dcfa0d618dc26bd27b3a1b49494b98d6eee97 Author: Steffen Sledz <sledz@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 <sledz@dresearch-fe.de> Signed-off-by: Martin Jansa <Martin.Jansa@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.olivier@outlook.com > From: paul.eggleton@linux.intel.com > To: jerome.olivier@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 [-- Attachment #2: Type: text/html, Size: 111030 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc LIBRARY_PATH sstate-cache issue 2015-10-21 12:10 ` gcc LIBRARY_PATH sstate-cache issue Jérôme OLIVIER @ 2015-10-21 20:58 ` Andre McCurdy 2015-11-02 13:51 ` Jérôme OLIVIER 0 siblings, 1 reply; 6+ messages in thread From: Andre McCurdy @ 2015-10-21 20:58 UTC (permalink / raw) To: Jérôme OLIVIER; +Cc: Paul Eggleton, yocto@yoctoproject.org On Wed, Oct 21, 2015 at 5:10 AM, Jérôme OLIVIER <jerome.olivier@outlook.com> wrote: > > 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 > Try using ${CC} to call the compiler instead of giving an explicit PATH. It's normal for the default sysroot compiled into the OE toolchain to be wrong or deliberately set to something invalid. You therefore need to take great care to always include the correct --sysroot option when calling the compiler or linker. The CC, LD, etc definitions provided by OE should always include the correct --sysroot option, but you will see problems if the package you're building over-rides or doesn't use these standard variables ( e.g. calls the compiler via ${CROSS_COMPILE}gcc ). > 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.olivier@outlook.com > >> From: paul.eggleton@linux.intel.com >> To: jerome.olivier@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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: gcc LIBRARY_PATH sstate-cache issue 2015-10-21 20:58 ` Andre McCurdy @ 2015-11-02 13:51 ` Jérôme OLIVIER 0 siblings, 0 replies; 6+ messages in thread From: Jérôme OLIVIER @ 2015-11-02 13:51 UTC (permalink / raw) To: Andre McCurdy; +Cc: Paul Eggleton, yocto@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 9060 bytes --] Hi Andre, Thanks a lot for this big hint that allowed me to find the cause of this problem. The problem came from the CMakeLists.txt of libB. It was overriding CMAKE_C_FLAGS cmake variable defined in the Yocto generated toolchain.cmake. CMAKE_C_FLGAS contains the "--sysroot" flag for gcc command. I don't know how it could work before and what in image/machine configurations' changes triggered this bug to show up. I don't know also how, when it was bugged, the build system populated the gcc's LIBRARY_PATH variable with sysroots path from the mirrored reference build's sstate-cache (build-machineA's sstate-cache). The most important is that state sharing cache is working fine. Thanks everyone for the help, Cheers -- Jérôme OLIVIER TEL : +337 52 46 29 25 @ : jerome.olivier@outlook.com > Date: Wed, 21 Oct 2015 13:58:53 -0700 > Subject: Re: [yocto] gcc LIBRARY_PATH sstate-cache issue > From: armccurdy@gmail.com > To: jerome.olivier@outlook.com > CC: paul.eggleton@linux.intel.com; yocto@yoctoproject.org > > On Wed, Oct 21, 2015 at 5:10 AM, Jérôme OLIVIER > <jerome.olivier@outlook.com> wrote: > > > > 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 > > > > Try using ${CC} to call the compiler instead of giving an explicit PATH. > > It's normal for the default sysroot compiled into the OE toolchain to > be wrong or deliberately set to something invalid. You therefore need > to take great care to always include the correct --sysroot option when > calling the compiler or linker. > > The CC, LD, etc definitions provided by OE should always include the > correct --sysroot option, but you will see problems if the package > you're building over-rides or doesn't use these standard variables ( > e.g. calls the compiler via ${CROSS_COMPILE}gcc ). > > > 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.olivier@outlook.com > > > >> From: paul.eggleton@linux.intel.com > >> To: jerome.olivier@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 > > [-- Attachment #2: Type: text/html, Size: 10812 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Disable sstate-cache for one recipe 2015-10-19 10:18 Disable sstate-cache for one recipe Jérôme OLIVIER 2015-10-19 11:21 ` Paul Eggleton @ 2015-10-19 12:12 ` Martin Jansa 1 sibling, 0 replies; 6+ messages in thread From: Martin Jansa @ 2015-10-19 12:12 UTC (permalink / raw) To: Jérôme OLIVIER; +Cc: yocto@yoctoproject.org [-- Attachment #1: Type: text/plain, Size: 657 bytes --] On Mon, Oct 19, 2015 at 10:18:41AM +0000, Jérôme OLIVIER wrote: > Hi everyone, > > 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? You can for oe-core and apply http://patchwork.openembedded.org/patch/17039/ > > Thank you, > > -- > Jérôme OLIVIER > TEL : +337 52 46 29 25 > @ : jerome.olivier@outlook.com > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 188 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-11-02 13:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-19 10:18 Disable sstate-cache for one recipe Jérôme OLIVIER 2015-10-19 11:21 ` Paul Eggleton 2015-10-21 12:10 ` gcc LIBRARY_PATH sstate-cache issue Jérôme OLIVIER 2015-10-21 20:58 ` Andre McCurdy 2015-11-02 13:51 ` Jérôme OLIVIER 2015-10-19 12:12 ` Disable sstate-cache for one recipe Martin Jansa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.