All of lore.kernel.org
 help / color / mirror / Atom feed
* 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

[-- 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
* 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

[-- 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
* 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

[-- 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

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

[-- 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
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.