[yocto] gcc LIBRARY_PATH sstate-cache issue

Jérôme OLIVIER jerome.olivier at outlook.com
Wed Oct 21 05:10:52 PDT 2015


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 at 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 at linux.intel.com>
    Signed-off-by: Brendan Le Foll <brendan.le.foll at intel.com>
    Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>

   * meta-openembedded:
commit 853dcfa0d618dc26bd27b3a1b49494b98d6eee97
Author: Steffen Sledz <sledz at 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 at dresearch-fe.de>
    Signed-off-by: Martin Jansa <Martin.Jansa at 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 at outlook.com

> From: paul.eggleton at linux.intel.com
> To: jerome.olivier at outlook.com
> CC: yocto at 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20151021/4272c575/attachment.html>


More information about the yocto mailing list