Re: [OE-core] [RFC 0/7] Postinstall improvements
On 10/04/2012 10:16 PM, Andreas Müller wrote:
> On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
> wrote:
>> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
>> wrote:
>>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>>> wrote:
On 09/20/2012 07:12 PM, Andreas Müller wrote:
> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
> wrote:
>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>> wrote:
>>>
>>>
>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
wrote:
> Hi,
>
> It's been quite a long time since I sent the first version of
> postinstall
> improvements which, after some debate, we decided it needed run-once
> support of postinst scriptlets on host. This patcheset (RFC actually)
> adds
> that.
>
> So, in order to achieve this goal I took advantage of
> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some
> postinst
> scriptlets is time consuming (even on host) and execute repeatedly,
> then we can postpone the running and run the scriplet just once. The
> idea is
> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory.
> When the
> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the
> scripts in
> this directory and execute them.
>
> This actual patchset does the above for the gtk icon cache generation
> which
> takes a very long time to run on target and even on some hosts.
>
> The people willing to give this patchset a test, are most than
> welcome. Also,
> please feel free to review.
>
> Thanks,
> Laurentiu
>
Thanks for taking care. I will give it a test tonight and hope to have
results tomorrow.
>>> It would be great if you could give it a try and let me know your
>>> results.
>>>
>> I removed gtk-native append in meta-oe, build from scratch and tested
>> the image. No issues so far - seems you have done a great job -
>> Thanks!
>>
> Aargh I really would like to consider this done but I found suspicious
> when browsing on the machine with the new image (hicolor- and
> gnome-icon-theme installed):
>
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
> date of 01.01.2000 (have no rtc backup on the machine). I would expect
> this file to have build host's date.
>
> So I checked the contents on the build machine in image's rootfs:
>
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
> 64,5KB (the version on the machine is 2,3MB!!).
Did you have any chance to debug the issue on your setup? I tried to
replicate your environment but I failed. Lots of build errors, so I gave
up. It would have taken me more time to make your setup work than
debugging the real problem.
Another alternative would be for you to prepare a tarball with all the
repos and configs that you use and put it somewhere where I can take it.
It would be easier for me to directly start debugging your issue.
>>> Sorry but I am occupied by other issues at the moment. Hope to find
>>> time at the weekend to add some debug messages to see what's going on.
>>>
>> Oh it's that simple: run_intercept_scriptlets is not called here (I
>> don't know what caused 'mini hicolor-icon-theme's cache)! You can
>> reproduce that e.g. by enabling buildhistory.
>>
>> I simply replaced in image.bbclass
>>
>> ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
>> by
>> ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"
>>
>> an now see larger caches for all my icon themes. But the sizes are
>> still different from those mentioned above. Will run-test tomorrow.
>>
>> Andreas
> Hey Laurentiu,
>
> With the minor change mentioned above I tested all my working images
> without issues. Thanks for taking care and speeding up first boot.
Thanks Andreas for your help with the tests and for finding the issue.
Unfortunately the patches will not be able to get into 1.3 (we're a
little late for that). I'll prepare another patch-set as soon as I'll
find some spare time and, hopefully, we'll get the patches in for 1.4.
Thanks,
Laurentiu
>
> Andreas
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [for-denzil][PATCH] gconf: Disable gtk support
Op 4 okt. 2012, om 04:46 heeft Franklin S. Cooper Jr het volgende geschreven: > From: Richard Purdie > > There are only a couple of helper utilities within gconf that need gtk+ as a > dependency and those are unused and pretty useless. We might as well drop > the dependency on gtk and allow more parallel builds by reducing dependency > bottlenecks. Except that gnome needs gconf-sanity-check, which is one of those "useless" binaries ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] toolchain-scripts.bbclass: Export M4
some packages use M4 variable from environment and sometimes
its hardcoded to /usr/bin/m4 if not found in environment. Lets
define it such that it is picked from path
Signed-off-by: Khem Raj
---
meta/classes/toolchain-scripts.bbclass |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 44284c3..6d8623c 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -26,6 +26,7 @@ toolchain_create_sdk_env_script () {
echo 'export OBJDUMP=${TARGET_PREFIX}objdump' >> $script
echo 'export AR=${TARGET_PREFIX}ar' >> $script
echo 'export NM=${TARGET_PREFIX}nm' >> $script
+ echo 'export M4=m4' >> $script
echo 'export TARGET_PREFIX=${TARGET_PREFIX}' >> $script
echo 'export CONFIGURE_FLAGS="--target=${TARGET_SYS}
--host=${TARGET_SYS} --build=${SDK_ARCH}-linux
--with-libtool-sysroot=${SDKTARGETSYSROOT}"' >> $script
if [ "${TARGET_OS}" = "darwin8" ]; then
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Only one copy of bitbake should be run against a build directory
On Thursday 04 October 2012 09:52:45 Khem Raj wrote: > On Thu, Oct 4, 2012 at 5:27 AM, Martin Jansa wrote: > > The same does apply to bitbake-diffsigs now after IIRC this patch > > http://git.openembedded.org/bitbake/commit/?id=cc70181659c07e04c205e178328 > > 46acf1ff31d28 before that I could use bitbake-diffsigs from any directory > > (not only TOPDIR) and also when build in the same directory was still > > running. > > and also to use runqemu Leaving the issue of devshell aside for a second, I agree that this is fairly unnecessary for the utilities; if we can avoid the checks for those we should. I'll look into this. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On 10/4/12 4:16 PM, Phil Blundell wrote:
On Thu, 2012-10-04 at 16:00 -0500, Mark Hatle wrote:
This is only one runtime. You have multiple compilers all capable of producing
software compatible with the same ABI. The default (oe) compiler is used,
unless otherwise configured. The alternative(s) are used for optimization of
various items. I mentioned ICC, because it's one that I know today people are
using and it is capable of replacing gcc in many applications.
If that's the case then it doesn't seem like it ought to be necessary to
override most of the variables you mentioned. Tools like ar, ranlib and
strip are generic to a binary format and should work fine with the
output from any compiler. Also, if you're linking with GNU libc then
the chances are that you need to use one of the GNU linkers (be that
ld.bfd or gold) since I suspect most third party link editors will not
work very well. And, if you have assembly source on hand, it's probably
going to be written in GAS dialect so selecting an alternative assembler
as ${AS} is unlikely to gain much.
I realize not everything will be overridden, and I even expect in many cases
only the CC and CXX will be defined.
I'm aware of at least one third party compiler that uses a different dialect
then GAS. And in that case the compiler and assembly would be overwritten..
(mind you anything that uses gas syntax would of course be incompatible and blow
up, which begs the question -- do you really want to use AS then?)
But I figure if we cover all of the cases then we should be good no matter what.
So, it kind of seems like the only variables you're likely to need to
change are CC, CXX and the corresponding FLAGS. I guess you might also
want to override F77 in theory though I'm not sure there are many people
using Fortran in an embedded environment.
I'm aware of one company that -was- using Fortran, I don't know if they still
are. (And they were not using the GNU F77)
Your proposed "toolchain-icc" override sounds like a reasonable enough
way to accomplish that, anyway. The only problem it doesn't seem to
solve is the use-case of "everything that supports icc, I want to build
with icc; everything that doesn't support icc, I want to build with
gcc". But I'm not sure this really matters much.
There needs to be a way to set the TOOLCHAIN 'type' on a blacklist or whitelist
basis. I.e. in a whitelist, you simply set it to 'gnu' (or whatever), which is
more or less what I'd expect the default behavior to be. Then for every recipe
you are aware of that works -- you'd overriver the TOOLCHAIN-pn_package w/ 'alt'.
Alternatively you could do it as a blacklist.. set TOOLCHAIN = 'alt' and then
blacklist items by setting the items to 'gnu' (or whatever).
Both have advantages.. personally I'd suggest the former rather then later
approach, it's easier to support and then you can focus porting efforts on the
packages that you believe you need the most optimizations in.
--Mark
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On Thu, 2012-10-04 at 16:00 -0500, Mark Hatle wrote:
> This is only one runtime. You have multiple compilers all capable of
> producing
> software compatible with the same ABI. The default (oe) compiler is used,
> unless otherwise configured. The alternative(s) are used for optimization of
> various items. I mentioned ICC, because it's one that I know today people
> are
> using and it is capable of replacing gcc in many applications.
If that's the case then it doesn't seem like it ought to be necessary to
override most of the variables you mentioned. Tools like ar, ranlib and
strip are generic to a binary format and should work fine with the
output from any compiler. Also, if you're linking with GNU libc then
the chances are that you need to use one of the GNU linkers (be that
ld.bfd or gold) since I suspect most third party link editors will not
work very well. And, if you have assembly source on hand, it's probably
going to be written in GAS dialect so selecting an alternative assembler
as ${AS} is unlikely to gain much.
So, it kind of seems like the only variables you're likely to need to
change are CC, CXX and the corresponding FLAGS. I guess you might also
want to override F77 in theory though I'm not sure there are many people
using Fortran in an embedded environment.
Your proposed "toolchain-icc" override sounds like a reasonable enough
way to accomplish that, anyway. The only problem it doesn't seem to
solve is the use-case of "everything that supports icc, I want to build
with icc; everything that doesn't support icc, I want to build with
gcc". But I'm not sure this really matters much.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On Thu, Oct 4, 2012 at 2:00 PM, Mark Hatle wrote:
> On 10/4/12 3:36 PM, Khem Raj wrote:
>>
>> On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle
>> wrote:
>>>
>>> We have an issue where we'd like to have an alternative toolchain
>>> (assembler, linker, compiler) available for our customers to selectively
>>> use. However, before we just go off and implement something, I'd like at
>>> least some basic consensus on what the best practice is for doing this
>>> work.
>>> Below is my attempt at an early proposal.
>>>
>>> Background
>>>
>>>
>>> Many companies have commercial / highly optimized toolchains for specific
>>> purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
>>> (potentially) better performance with some applications a mechanism to
>>> both
>>> provide the hooks for the alternative toolchain as well as a way to
>>> active
>>> it per-package is desired.
>>>
>>> This work assumes that the third party toolchain is generally compatible
>>> with the idea of sysroots, linking to the libc provided by OE, and
>>> generally
>>> compatible with GNU conventions.
>>>
>>> However, as part of the third party toolchain, it may not be GNU
>>> compatible.
>>> This means many Open Source applications simply may not work with this
>>> toolchain. That means that we need to have a way for a toolchain to
>>> blacklist (or whitelist) specific recipes. This way only supported
>>> components can be built by the user, avoiding numerous complaints.
>>>
>>> Currently OE has a method to generate an SDK based on the GNU toolchain.
>>> We
>>> would like to be able to also export the external toolchain along with
>>> the
>>> SDK, effectively providing both the GNU toolchain and the third party
>>> toolchain using the common sysroot.
>>>
>>> We need a way to active the third party toolchain on a per-package basis.
>>
>>
>> Per package bases is a bit iffy from my POV if you consider the compiler
>> runtime
>> and C library runtime and so forth. Is it intended to just compile and
>> be able to
>> cope with the default runtimes on images or do you also intend to figure
>> out
>> ways for multiple runtimes to live together.
>
>
> This is only one runtime. You have multiple compilers all capable of
> producing software compatible with the same ABI. The default (oe) compiler
> is used, unless otherwise configured. The alternative(s) are used for
> optimization of various items. I mentioned ICC, because it's one that I
> know today people are using and it is capable of replacing gcc in many
> applications.
Thanks that clarifies the scope. I thought you were going for a
general solution where you
could insert any toolchain.
>
> The issue is that I want to enable someone to use an alternative compiler,
> but I don't want to do anything beyond enabling it if it doesn't work.
>
>
>>> This activation will need to use the existing sysroot, but be able to
>>> pass
>>> different C, C++, LD, AS and other flags as specified by the third party
>>> toolchain.
>>
>>
>> that sort of answers the above. So we are assuming that toolchain that
>> can interoperate
>> will be using GNU runtime
>>
>> There are cases where you might want something like ELLCC which avoids
>> complete GPL runtime e.g.
>> I think it could be divided into runtime + tools where runtime lives
>> in a different layer but
>> essentially offering to let people use builtin C library and runtime
>> may not be a bad choice
>
>
> When the runtime changes, I consider that to be a different abi and outside
> the scope of this. Thats where the machine/multilib/etc configuration items
> come into play. (I.e. some architectures support an alternative compiler
> for bare metal applications -- in those cases the canonical arch is no
> longer -linux[-gnu]... so they would simply be treated as a different
> architecture.)
>
>
>>
>>>
>>> Finally third party toolchains should be implemented as layers that can
>>> easily plug into OE.
>>
>>
>> agreed. I think we need to document the interfaces in OE-Core for this
>> too so that
>> people can rely on the interface. Otherwise it will be constant pain
>> for keeping those
>> layers working together.
>
>
> Exactly.. I don't want people coming to me saying I want XYZ compiler, but
> it's implemented for my semi-conduction specific Linux and won't work with
> your OSV based Linux. That doesn't help anyone (unless they are
> intentionally trying to be incompatible!) So if we can provide a functional
> best practice and example of how to do this, then when people want to
> provide (and use) a secondary toolchain -- it's available to them.
>
>
>>>
>>> Implementation
>>> -
>>>
>>> Add an OVERRIDE to specify the alternative toolchain. Can this be done
>>> within the layer by doing something like:
>>>
>>> OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
>>>
>>> TOOLCHAIN = "gnu" (or "icc")
>>>
>>> To activate the toolchain you would use things like:
>>>
>>> TOOLCHAIN_pn-bash = 'icc'
>>>
>>> To defin
Re: [OE-core] RFC: Secondary Toolchain
On 10/4/12 3:36 PM, Khem Raj wrote:
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler) available for our customers to selectively
use. However, before we just go off and implement something, I'd like at
least some basic consensus on what the best practice is for doing this work.
Below is my attempt at an early proposal.
Background
Many companies have commercial / highly optimized toolchains for specific
purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
(potentially) better performance with some applications a mechanism to both
provide the hooks for the alternative toolchain as well as a way to active
it per-package is desired.
This work assumes that the third party toolchain is generally compatible
with the idea of sysroots, linking to the libc provided by OE, and generally
compatible with GNU conventions.
However, as part of the third party toolchain, it may not be GNU compatible.
This means many Open Source applications simply may not work with this
toolchain. That means that we need to have a way for a toolchain to
blacklist (or whitelist) specific recipes. This way only supported
components can be built by the user, avoiding numerous complaints.
Currently OE has a method to generate an SDK based on the GNU toolchain. We
would like to be able to also export the external toolchain along with the
SDK, effectively providing both the GNU toolchain and the third party
toolchain using the common sysroot.
We need a way to active the third party toolchain on a per-package basis.
Per package bases is a bit iffy from my POV if you consider the compiler runtime
and C library runtime and so forth. Is it intended to just compile and
be able to
cope with the default runtimes on images or do you also intend to figure out
ways for multiple runtimes to live together.
This is only one runtime. You have multiple compilers all capable of producing
software compatible with the same ABI. The default (oe) compiler is used,
unless otherwise configured. The alternative(s) are used for optimization of
various items. I mentioned ICC, because it's one that I know today people are
using and it is capable of replacing gcc in many applications.
The issue is that I want to enable someone to use an alternative compiler, but I
don't want to do anything beyond enabling it if it doesn't work.
This activation will need to use the existing sysroot, but be able to pass
different C, C++, LD, AS and other flags as specified by the third party
toolchain.
that sort of answers the above. So we are assuming that toolchain that
can interoperate
will be using GNU runtime
There are cases where you might want something like ELLCC which avoids
complete GPL runtime e.g.
I think it could be divided into runtime + tools where runtime lives
in a different layer but
essentially offering to let people use builtin C library and runtime
may not be a bad choice
When the runtime changes, I consider that to be a different abi and outside the
scope of this. Thats where the machine/multilib/etc configuration items come
into play. (I.e. some architectures support an alternative compiler for bare
metal applications -- in those cases the canonical arch is no longer
-linux[-gnu]... so they would simply be treated as a different architecture.)
Finally third party toolchains should be implemented as layers that can
easily plug into OE.
agreed. I think we need to document the interfaces in OE-Core for this
too so that
people can rely on the interface. Otherwise it will be constant pain
for keeping those
layers working together.
Exactly.. I don't want people coming to me saying I want XYZ compiler, but it's
implemented for my semi-conduction specific Linux and won't work with your OSV
based Linux. That doesn't help anyone (unless they are intentionally trying to
be incompatible!) So if we can provide a functional best practice and example
of how to do this, then when people want to provide (and use) a secondary
toolchain -- it's available to them.
Implementation
-
Add an OVERRIDE to specify the alternative toolchain. Can this be done
within the layer by doing something like:
OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
TOOLCHAIN = "gnu" (or "icc")
To activate the toolchain you would use things like:
TOOLCHAIN_pn-bash = 'icc'
To define the correct behavior for the toolchain, the following would need
to be defined (with _toolchain-):
TARGET_CPPFLAGS
TARGET_CFLAGS
TARGET_CXXFLAGS
TARGET_LDFLAGS
CC
CXX
F77
CPP
LD
CCLD
AR
AS
RANLIB
STRIP
OBJCOPY
OBJDUMP
NM
FULL_OPTIMIZATIONS
DEBUG_OPTIMIZATION
Is anyone aware of any other items that may require additional items? Will
the above actually work? Using the override of the TOOLCHAIN_… will that
actually change the override values or do we get stuck?
Comments/suggestions appreciated!
--Mark
__
Re: [OE-core] RFC: Secondary Toolchain
On Thu, Oct 4, 2012 at 11:02 AM, Mark Hatle wrote:
> We have an issue where we'd like to have an alternative toolchain
> (assembler, linker, compiler) available for our customers to selectively
> use. However, before we just go off and implement something, I'd like at
> least some basic consensus on what the best practice is for doing this work.
> Below is my attempt at an early proposal.
>
> Background
>
>
> Many companies have commercial / highly optimized toolchains for specific
> purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
> (potentially) better performance with some applications a mechanism to both
> provide the hooks for the alternative toolchain as well as a way to active
> it per-package is desired.
>
> This work assumes that the third party toolchain is generally compatible
> with the idea of sysroots, linking to the libc provided by OE, and generally
> compatible with GNU conventions.
>
> However, as part of the third party toolchain, it may not be GNU compatible.
> This means many Open Source applications simply may not work with this
> toolchain. That means that we need to have a way for a toolchain to
> blacklist (or whitelist) specific recipes. This way only supported
> components can be built by the user, avoiding numerous complaints.
>
> Currently OE has a method to generate an SDK based on the GNU toolchain. We
> would like to be able to also export the external toolchain along with the
> SDK, effectively providing both the GNU toolchain and the third party
> toolchain using the common sysroot.
>
> We need a way to active the third party toolchain on a per-package basis.
Per package bases is a bit iffy from my POV if you consider the compiler runtime
and C library runtime and so forth. Is it intended to just compile and
be able to
cope with the default runtimes on images or do you also intend to figure out
ways for multiple runtimes to live together.
> This activation will need to use the existing sysroot, but be able to pass
> different C, C++, LD, AS and other flags as specified by the third party
> toolchain.
that sort of answers the above. So we are assuming that toolchain that
can interoperate
will be using GNU runtime
There are cases where you might want something like ELLCC which avoids
complete GPL runtime e.g.
I think it could be divided into runtime + tools where runtime lives
in a different layer but
essentially offering to let people use builtin C library and runtime
may not be a bad choice
>
> Finally third party toolchains should be implemented as layers that can
> easily plug into OE.
agreed. I think we need to document the interfaces in OE-Core for this
too so that
people can rely on the interface. Otherwise it will be constant pain
for keeping those
layers working together.
>
> Implementation
> -
>
> Add an OVERRIDE to specify the alternative toolchain. Can this be done
> within the layer by doing something like:
>
> OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
>
> TOOLCHAIN = "gnu" (or "icc")
>
> To activate the toolchain you would use things like:
>
> TOOLCHAIN_pn-bash = 'icc'
>
> To define the correct behavior for the toolchain, the following would need
> to be defined (with _toolchain-):
>
> TARGET_CPPFLAGS
> TARGET_CFLAGS
> TARGET_CXXFLAGS
> TARGET_LDFLAGS
> CC
> CXX
> F77
> CPP
> LD
> CCLD
> AR
> AS
> RANLIB
> STRIP
> OBJCOPY
> OBJDUMP
> NM
> FULL_OPTIMIZATIONS
> DEBUG_OPTIMIZATION
>
> Is anyone aware of any other items that may require additional items? Will
> the above actually work? Using the override of the TOOLCHAIN_… will that
> actually change the override values or do we get stuck?
>
> Comments/suggestions appreciated!
> --Mark
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On 10/4/12 2:03 PM, McClintock Matthew-B29882 wrote:
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle wrote:
We have an issue where we'd like to have an alternative toolchain
(assembler, linker, compiler) available for our customers to selectively
use. However, before we just go off and implement something, I'd like at
least some basic consensus on what the best practice is for doing this work.
Below is my attempt at an early proposal.
Background
Many companies have commercial / highly optimized toolchains for specific
purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
(potentially) better performance with some applications a mechanism to both
provide the hooks for the alternative toolchain as well as a way to active
it per-package is desired.
This work assumes that the third party toolchain is generally compatible
with the idea of sysroots, linking to the libc provided by OE, and generally
compatible with GNU conventions.
However, as part of the third party toolchain, it may not be GNU compatible.
This means many Open Source applications simply may not work with this
toolchain. That means that we need to have a way for a toolchain to
blacklist (or whitelist) specific recipes. This way only supported
components can be built by the user, avoiding numerous complaints.
Currently OE has a method to generate an SDK based on the GNU toolchain. We
would like to be able to also export the external toolchain along with the
SDK, effectively providing both the GNU toolchain and the third party
toolchain using the common sysroot.
We need a way to active the third party toolchain on a per-package basis.
This activation will need to use the existing sysroot, but be able to pass
different C, C++, LD, AS and other flags as specified by the third party
toolchain.
Finally third party toolchains should be implemented as layers that can
easily plug into OE.
Implementation
-
Add an OVERRIDE to specify the alternative toolchain. Can this be done
within the layer by doing something like:
OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
TOOLCHAIN = "gnu" (or "icc")
To activate the toolchain you would use things like:
TOOLCHAIN_pn-bash = 'icc'
To define the correct behavior for the toolchain, the following would need
to be defined (with _toolchain-):
TARGET_CPPFLAGS
TARGET_CFLAGS
TARGET_CXXFLAGS
TARGET_LDFLAGS
CC
CXX
F77
CPP
LD
CCLD
AR
AS
RANLIB
STRIP
OBJCOPY
OBJDUMP
NM
FULL_OPTIMIZATIONS
DEBUG_OPTIMIZATION
Is anyone aware of any other items that may require additional items? Will
the above actually work? Using the override of the TOOLCHAIN_… will that
actually change the override values or do we get stuck?
This seems orthogonal to actually implementing the recipe which would
procide 'icc'?
That is correct. I'm trying to establish a best practice for the layer
configuration, as well as general distribution/recipe configuration.
What I really don't want to see is 5 companies implementing similar
functionality and doing it in a completely incompatible way. If the variables
and override mechanism above is reasonable, then it gives people a roadmap to
get started.
--Mark
-M
Comments/suggestions appreciated!
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC 0/7] Postinstall improvements
On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
wrote:
> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
> wrote:
>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>> wrote:
>>>
>>>
>>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
wrote:
> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
> wrote:
>>
>>
>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>> wrote:
Hi,
It's been quite a long time since I sent the first version of
postinstall
improvements which, after some debate, we decided it needed run-once
support of postinst scriptlets on host. This patcheset (RFC actually)
adds
that.
So, in order to achieve this goal I took advantage of
ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some
postinst
scriptlets is time consuming (even on host) and execute repeatedly,
then we can postpone the running and run the scriplet just once. The
idea is
to put the scriptlet in the ${WORKDIR}/intercept_scripts directory.
When the
ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the
scripts in
this directory and execute them.
This actual patchset does the above for the gtk icon cache generation
which
takes a very long time to run on target and even on some hosts.
The people willing to give this patchset a test, are most than
welcome. Also,
please feel free to review.
Thanks,
Laurentiu
>>> Thanks for taking care. I will give it a test tonight and hope to have
>>> results tomorrow.
>> It would be great if you could give it a try and let me know your
>> results.
>>
> I removed gtk-native append in meta-oe, build from scratch and tested
> the image. No issues so far - seems you have done a great job -
> Thanks!
>
Aargh I really would like to consider this done but I found suspicious
when browsing on the machine with the new image (hicolor- and
gnome-icon-theme installed):
* in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
* /usr/share/icons/hicolor/icon-theme.cache is there but it has the
date of 01.01.2000 (have no rtc backup on the machine). I would expect
this file to have build host's date.
So I checked the contents on the build machine in image's rootfs:
* in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
* /usr/share/icons/hicolor/icon-theme.cache is there but has only
64,5KB (the version on the machine is 2,3MB!!).
>>> Did you have any chance to debug the issue on your setup? I tried to
>>> replicate your environment but I failed. Lots of build errors, so I gave
>>> up. It would have taken me more time to make your setup work than
>>> debugging the real problem.
>>>
>>> Another alternative would be for you to prepare a tarball with all the
>>> repos and configs that you use and put it somewhere where I can take it.
>>> It would be easier for me to directly start debugging your issue.
>>>
>> Sorry but I am occupied by other issues at the moment. Hope to find
>> time at the weekend to add some debug messages to see what's going on.
>>
> Oh it's that simple: run_intercept_scriptlets is not called here (I
> don't know what caused 'mini hicolor-icon-theme's cache)! You can
> reproduce that e.g. by enabling buildhistory.
>
> I simply replaced in image.bbclass
>
> ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
> by
> ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"
>
> an now see larger caches for all my icon themes. But the sizes are
> still different from those mentioned above. Will run-test tomorrow.
>
> Andreas
Hey Laurentiu,
With the minor change mentioned above I tested all my working images
without issues. Thanks for taking care and speeding up first boot.
Andreas
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On Thu, Oct 4, 2012 at 1:02 PM, Mark Hatle wrote:
> We have an issue where we'd like to have an alternative toolchain
> (assembler, linker, compiler) available for our customers to selectively
> use. However, before we just go off and implement something, I'd like at
> least some basic consensus on what the best practice is for doing this work.
> Below is my attempt at an early proposal.
>
> Background
>
>
> Many companies have commercial / highly optimized toolchains for specific
> purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
> (potentially) better performance with some applications a mechanism to both
> provide the hooks for the alternative toolchain as well as a way to active
> it per-package is desired.
>
> This work assumes that the third party toolchain is generally compatible
> with the idea of sysroots, linking to the libc provided by OE, and generally
> compatible with GNU conventions.
>
> However, as part of the third party toolchain, it may not be GNU compatible.
> This means many Open Source applications simply may not work with this
> toolchain. That means that we need to have a way for a toolchain to
> blacklist (or whitelist) specific recipes. This way only supported
> components can be built by the user, avoiding numerous complaints.
>
> Currently OE has a method to generate an SDK based on the GNU toolchain. We
> would like to be able to also export the external toolchain along with the
> SDK, effectively providing both the GNU toolchain and the third party
> toolchain using the common sysroot.
>
> We need a way to active the third party toolchain on a per-package basis.
> This activation will need to use the existing sysroot, but be able to pass
> different C, C++, LD, AS and other flags as specified by the third party
> toolchain.
>
> Finally third party toolchains should be implemented as layers that can
> easily plug into OE.
>
> Implementation
> -
>
> Add an OVERRIDE to specify the alternative toolchain. Can this be done
> within the layer by doing something like:
>
> OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
>
> TOOLCHAIN = "gnu" (or "icc")
>
> To activate the toolchain you would use things like:
>
> TOOLCHAIN_pn-bash = 'icc'
>
> To define the correct behavior for the toolchain, the following would need
> to be defined (with _toolchain-):
>
> TARGET_CPPFLAGS
> TARGET_CFLAGS
> TARGET_CXXFLAGS
> TARGET_LDFLAGS
> CC
> CXX
> F77
> CPP
> LD
> CCLD
> AR
> AS
> RANLIB
> STRIP
> OBJCOPY
> OBJDUMP
> NM
> FULL_OPTIMIZATIONS
> DEBUG_OPTIMIZATION
>
> Is anyone aware of any other items that may require additional items? Will
> the above actually work? Using the override of the TOOLCHAIN_… will that
> actually change the override values or do we get stuck?
This seems orthogonal to actually implementing the recipe which would
procide 'icc'?
-M
>
> Comments/suggestions appreciated!
> --Mark
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
On 10/4/12 1:15 PM, Trevor Woerner wrote:
I'm curious to know if anyone (I certainly wouldn't be able to!) can
take a guess whether this would "play nicely" with external
toolchains?
In other words, if some recipe is already PROVIDES'ing
virtual/${TARGET_PREFIX}gcc etc would the correct toolchain be used
for the special packages needing the secondary toolchain?
My expectations is that any existing dependency set will be managed and
maintained by the existing primary toolchain, unless a given recipe has a
specific dependency on a secondary toolchain item.
I.e. the example above will -always- be the primary toolchain from a dependency
resolution standpoint..
If the recipe adds "virtual/icc", then something, such as icc, needs to exist to
provide that.
Does this seem like a reasonable behavior and expectation? (The thing to
remember is this secondary toolchain is just that.. an alternative to the
primary for specific users and NOT general purpose)
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Secondary Toolchain
I'm curious to know if anyone (I certainly wouldn't be able to!) can
take a guess whether this would "play nicely" with external
toolchains?
In other words, if some recipe is already PROVIDES'ing
virtual/${TARGET_PREFIX}gcc etc would the correct toolchain be used
for the special packages needing the secondary toolchain?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] RFC: Secondary Toolchain
We have an issue where we'd like to have an alternative toolchain (assembler,
linker, compiler) available for our customers to selectively use. However,
before we just go off and implement something, I'd like at least some basic
consensus on what the best practice is for doing this work. Below is my attempt
at an early proposal.
Background
Many companies have commercial / highly optimized toolchains for specific
purpose, such as ICC from Intel, LLVM, ARM specific toolchain, etc.. For
(potentially) better performance with some applications a mechanism to both
provide the hooks for the alternative toolchain as well as a way to active it
per-package is desired.
This work assumes that the third party toolchain is generally compatible with
the idea of sysroots, linking to the libc provided by OE, and generally
compatible with GNU conventions.
However, as part of the third party toolchain, it may not be GNU compatible.
This means many Open Source applications simply may not work with this
toolchain. That means that we need to have a way for a toolchain to blacklist
(or whitelist) specific recipes. This way only supported components can be
built by the user, avoiding numerous complaints.
Currently OE has a method to generate an SDK based on the GNU toolchain. We
would like to be able to also export the external toolchain along with the SDK,
effectively providing both the GNU toolchain and the third party toolchain using
the common sysroot.
We need a way to active the third party toolchain on a per-package basis. This
activation will need to use the existing sysroot, but be able to pass different
C, C++, LD, AS and other flags as specified by the third party toolchain.
Finally third party toolchains should be implemented as layers that can easily
plug into OE.
Implementation
-
Add an OVERRIDE to specify the alternative toolchain. Can this be done within
the layer by doing something like:
OVERRIDE_append = ":toolchain-${TOOLCHAIN}"
TOOLCHAIN = "gnu" (or "icc")
To activate the toolchain you would use things like:
TOOLCHAIN_pn-bash = 'icc'
To define the correct behavior for the toolchain, the following would need to be
defined (with _toolchain-):
TARGET_CPPFLAGS
TARGET_CFLAGS
TARGET_CXXFLAGS
TARGET_LDFLAGS
CC
CXX
F77
CPP
LD
CCLD
AR
AS
RANLIB
STRIP
OBJCOPY
OBJDUMP
NM
FULL_OPTIMIZATIONS
DEBUG_OPTIMIZATION
Is anyone aware of any other items that may require additional items? Will the
above actually work? Using the override of the TOOLCHAIN_… will that actually
change the override values or do we get stuck?
Comments/suggestions appreciated!
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
On Thu, Oct 04, 2012 at 09:55:01AM -0700, Khem Raj wrote:
> On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
> >
> > -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> > -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> > +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES",
> > "xscale", "-march=armv4t", "", d)}"
> > +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
> > "-march=armv4t", "", d)}"
>
> I would rather try to remove this option completely if possible. I
> wonder if we still need to target armv4t when building on xscale
> may be the reason it was added is no more relevant ?
I think the same (as written in commit message). Now it won't be used by
default at least (only if someone asks for DEFAULTTUNE xscale for
webkit-gtk or cairo).
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 3/7] tune-cortexr4: fix march value
On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
>
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
> "-march=armv7-m", "", d)}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
> "-march=armv7-r", "", d)}"
yeah this is ok
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
On Thu, Oct 4, 2012 at 6:23 AM, Martin Jansa wrote:
>
> -TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
> -TUNE_CCARGS_pn-cairo = "-march=armv4t"
> +TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
> "-march=armv4t", "", d)}"
> +TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
> "-march=armv4t", "", d)}"
I would rather try to remove this option completely if possible. I
wonder if we still need to target armv4t when building on xscale
may be the reason it was added is no more relevant ?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Only one copy of bitbake should be run against a build directory
On Thu, Oct 4, 2012 at 5:27 AM, Martin Jansa wrote: > On Thu, Oct 04, 2012 at 01:07:46PM +0100, Phil Blundell wrote: >> Since updating my copy of bitbake to one which does this extra locking, >> I've come to realise that the constraint of having only one copy of >> bitbake running is a bit of a nuisance when making use of devshells. I >> used to quite often have one or two long-running devshells for packages >> that I was actively working on, and then in parallel with that would use >> bitbake to recompile other things. With the new locking mechanism, as >> soon as I have a single devshell open I am now prohibited from using >> bitbake for anything else in that same build directory. >> >> Would it be reasonable to exempt devshells from that locking or is there >> some compelling reason why they need to be serialised? > > The same does apply to bitbake-diffsigs now after IIRC this patch > http://git.openembedded.org/bitbake/commit/?id=cc70181659c07e04c205e17832846acf1ff31d28 > before that I could use bitbake-diffsigs from any directory (not only > TOPDIR) and also when build in the same directory was still running. > and also to use runqemu > Cheers, > > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
On 10/04/2012 08:50 AM, Maupin, Chase wrote: -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, October 04, 2012 9:30 AM To: Maupin, Chase Cc: openembedded-core@lists.openembedded.org Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross On Thu, 2012-10-04 at 14:06 +, Maupin, Chase wrote: I tried the following to help narrow this down. Please let me know if there is something else I could try to help narrow the issue. I ran: bitbake -c cleanall libtool bitbake libtool Each time it failed I would get a list of the contents of the work directory and the stamps directory. My goal here was to be able to find what changed between a pass and a fail. I kept running the test above until I had a consistent failure, and there were no new packages being added into my work directory and no new stamps being created. Basically this told me that all the packages that were going to be built from doing "bitbake libtool" were built and that the only package being built was libtool itself. I then changed my build steps to do: bitbake -c cleanall libtool bitbake libtool-cross bitbake libtool This passed on the first run. I captured the same work directory contents and stamps contents and then did a diff to see what had changed between these builds. The diffs were: For Stamps diff libtool-failed-stamps libtool-passed-stamps --- /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps libtool-passed-stamps --- libtool-failed-stamps 2012-10-04 09:11:27.909881710 -0500 +++ libtool-passed-stamps 2012-10-04 09:14:33.997328844 -0500 @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul external-arago-toolchain-1.0- r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9 external-arago-toolchain-1.0-r2.do_unpack external-arago-toolchain-1.0- r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47 +libtool-2.4.2-r3.0.do_build libtool-2.4.2-r3.0.do_cleansstate libtool-2.4.2- r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3 +libtool-2.4.2-r3.0.do_compile +libtool-2.4.2- r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d +libtool-2.4.2-r3.0.do_configure +libtool-2.4.2- r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4 libtool-2.4.2-r3.0.do_create_srcipk libtool-2.4.2- r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86 libtool-2.4.2-r3.0.do_fetch libtool-2.4.2- r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060 +libtool-2.4.2-r3.0.do_install +libtool-2.4.2- r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c +libtool-2.4.2-r3.0.do_package.am335x-evm +libtool-2.4.2- r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8 +libtool-2.4.2-r3.0.do_package_write +libtool-2.4.2-r3.0.do_package_write_ipk +libtool-2.4.2- r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af3 0 libtool-2.4.2-r3.0.do_patch libtool-2.4.2- r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc libtool-2.4.2-r3.0.do_populate_lic libtool-2.4.2- r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373 +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm +libtool-2.4.2- r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1 libtool-2.4.2-r3.0.do_unpack libtool-2.4.2- r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e +libtool-cross-2.4.2-r3.1.do_build +libtool-cross-2.4.2-r3.1.do_compile +libtool-cross-2.4.2- r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24 +libtool-cross-2.4.2-r3.1.do_configure +libtool-cross-2.4.2- r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b +libtool-cross-2.4.2-r3.1.do_create_srcipk +libtool-cross-2.4.2- r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221 +libtool-cross-2.4.2-r3.1.do_fetch +libtool-cross-2.4.2- r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5 +libtool-cross-2.4.2-r3.1.do_install +libtool-cross-2.4.2- r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b +libtool-cross-2.4.2-r3.1.do_package.am335x-evm +libtool-cross-2.4.2- r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2 +libtool-cross-2.4.2-r3.1.do_package_write +libtool-cross-2.4.2-r3.1.do_package_write_ipk +libtool-cross-2.4.2- r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1 a +libtool-cross-2.4.2-r3.1.do_patch +libtool-cross-2.4.2- r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d +libtool-cross-2.4.2-r3.1.do_populate_lic +libtool-cross-2.4.2- r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm +libtool-cross-2.4.2- r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0 +libtool-cross-2.4.2-r3.1.do_unpack +libtool-cross-2.4.2- r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585 linux-libc-headers-3.2-r1.do_compile linux-libc-headers-3.2- r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b linux-libc-headers-3.2-r
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
> -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Thursday, October 04, 2012 9:30 AM > To: Maupin, Chase > Cc: openembedded-core@lists.openembedded.org > Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > On Thu, 2012-10-04 at 14:06 +, Maupin, Chase wrote: > > I tried the following to help narrow this down. Please let me > know if there is something else I could try to help narrow the > issue. I ran: > > > > bitbake -c cleanall libtool > > bitbake libtool > > > > Each time it failed I would get a list of the contents of the > work directory and the stamps directory. My goal here was to be > able to find what changed between a pass and a fail. I kept > running the test above until I had a consistent failure, and > there were no new packages being added into my work directory and > no new stamps being created. Basically this told me that all the > packages that were going to be built from doing "bitbake libtool" > were built and that the only package being built was libtool > itself. > > > > I then changed my build steps to do: > > > > bitbake -c cleanall libtool > > bitbake libtool-cross > > bitbake libtool > > > > This passed on the first run. I captured the same work > directory contents and stamps contents and then did a diff to see > what had changed between these builds. The diffs were: > > > > For Stamps diff libtool-failed-stamps libtool-passed-stamps > > --- > > /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps > libtool-passed-stamps > > --- libtool-failed-stamps 2012-10-04 09:11:27.909881710 -0500 > > +++ libtool-passed-stamps 2012-10-04 09:14:33.997328844 -0500 > > @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul > > external-arago-toolchain-1.0- > r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9 > > external-arago-toolchain-1.0-r2.do_unpack > > external-arago-toolchain-1.0- > r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47 > > +libtool-2.4.2-r3.0.do_build > > libtool-2.4.2-r3.0.do_cleansstate > > libtool-2.4.2- > r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3 > > +libtool-2.4.2-r3.0.do_compile > > +libtool-2.4.2- > r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d > > +libtool-2.4.2-r3.0.do_configure > > +libtool-2.4.2- > r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4 > > libtool-2.4.2-r3.0.do_create_srcipk > > libtool-2.4.2- > r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86 > > libtool-2.4.2-r3.0.do_fetch > > libtool-2.4.2- > r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060 > > +libtool-2.4.2-r3.0.do_install > > +libtool-2.4.2- > r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c > > +libtool-2.4.2-r3.0.do_package.am335x-evm > > +libtool-2.4.2- > r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8 > > +libtool-2.4.2-r3.0.do_package_write > > +libtool-2.4.2-r3.0.do_package_write_ipk > > +libtool-2.4.2- > r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af3 > 0 > > libtool-2.4.2-r3.0.do_patch > > libtool-2.4.2- > r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc > > libtool-2.4.2-r3.0.do_populate_lic > > libtool-2.4.2- > r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373 > > +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm > > +libtool-2.4.2- > r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1 > > libtool-2.4.2-r3.0.do_unpack > > libtool-2.4.2- > r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e > > +libtool-cross-2.4.2-r3.1.do_build > > +libtool-cross-2.4.2-r3.1.do_compile > > +libtool-cross-2.4.2- > r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24 > > +libtool-cross-2.4.2-r3.1.do_configure > > +libtool-cross-2.4.2- > r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b > > +libtool-cross-2.4.2-r3.1.do_create_srcipk > > +libtool-cross-2.4.2- > r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221 > > +libtool-cross-2.4.2-r3.1.do_fetch > > +libtool-cross-2.4.2- > r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5 > > +libtool-cross-2.4.2-r3.1.do_install > > +libtool-cross-2.4.2- > r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b > > +libtool-cross-2.4.2-r3.1.do_package.am335x-evm > > +libtool-cross-2.4.2- > r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2 > > +libtool-cross-2.4.2-r3.1.do_package_write > > +libtool-cross-2.4.2-r3.1.do_package_write_ipk > > +libtool-cross-2.4.2- > r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1 > a > > +libtool-cross-2.4.2-r3.1.do_patch > > +libtool-cross-2.4.2- > r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d > > +libtool-cross-2.4.2-r3.1.do_populate_lic > > +libtool-cross-2.4.2- > r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a > > +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm > > +libtool-cross-2.4.2- > r3.1.do_populate_sysroot.sigdata.8c61b5
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
On Thu, 2012-10-04 at 14:06 +, Maupin, Chase wrote: > I tried the following to help narrow this down. Please let me know if there > is something else I could try to help narrow the issue. I ran: > > bitbake -c cleanall libtool > bitbake libtool > > Each time it failed I would get a list of the contents of the work directory > and the stamps directory. My goal here was to be able to find what changed > between a pass and a fail. I kept running the test above until I had a > consistent failure, and there were no new packages being added into my work > directory and no new stamps being created. Basically this told me that all > the packages that were going to be built from doing "bitbake libtool" were > built and that the only package being built was libtool itself. > > I then changed my build steps to do: > > bitbake -c cleanall libtool > bitbake libtool-cross > bitbake libtool > > This passed on the first run. I captured the same work directory contents > and stamps contents and then did a diff to see what had changed between these > builds. The diffs were: > > For Stamps diff libtool-failed-stamps libtool-passed-stamps > --- > /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps > libtool-passed-stamps > --- libtool-failed-stamps 2012-10-04 09:11:27.909881710 -0500 > +++ libtool-passed-stamps 2012-10-04 09:14:33.997328844 -0500 > @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul > > external-arago-toolchain-1.0-r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9 > external-arago-toolchain-1.0-r2.do_unpack > > external-arago-toolchain-1.0-r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47 > +libtool-2.4.2-r3.0.do_build > libtool-2.4.2-r3.0.do_cleansstate > libtool-2.4.2-r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3 > +libtool-2.4.2-r3.0.do_compile > +libtool-2.4.2-r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d > +libtool-2.4.2-r3.0.do_configure > +libtool-2.4.2-r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4 > libtool-2.4.2-r3.0.do_create_srcipk > libtool-2.4.2-r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86 > libtool-2.4.2-r3.0.do_fetch > libtool-2.4.2-r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060 > +libtool-2.4.2-r3.0.do_install > +libtool-2.4.2-r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c > +libtool-2.4.2-r3.0.do_package.am335x-evm > +libtool-2.4.2-r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8 > +libtool-2.4.2-r3.0.do_package_write > +libtool-2.4.2-r3.0.do_package_write_ipk > +libtool-2.4.2-r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af30 > libtool-2.4.2-r3.0.do_patch > libtool-2.4.2-r3.0.do_patch.sigdata.7d028f6dc6a1bdf32aadc29a6444bebc > libtool-2.4.2-r3.0.do_populate_lic > libtool-2.4.2-r3.0.do_populate_lic.sigdata.ebd50cceb0903e1b277ad6f533055373 > +libtool-2.4.2-r3.0.do_populate_sysroot.am335x-evm > +libtool-2.4.2-r3.0.do_populate_sysroot.sigdata.43f8d1df81e38dacd301eed5599094f1 > libtool-2.4.2-r3.0.do_unpack > libtool-2.4.2-r3.0.do_unpack.sigdata.f97c2643ec8f5752b2537f305a45ca7e > +libtool-cross-2.4.2-r3.1.do_build > +libtool-cross-2.4.2-r3.1.do_compile > +libtool-cross-2.4.2-r3.1.do_compile.sigdata.c04f058e41aabe9001f0b82764d51d24 > +libtool-cross-2.4.2-r3.1.do_configure > +libtool-cross-2.4.2-r3.1.do_configure.sigdata.b37940faf1adfcc783e7a66eff351d4b > +libtool-cross-2.4.2-r3.1.do_create_srcipk > +libtool-cross-2.4.2-r3.1.do_create_srcipk.sigdata.37082cdfd6eb100923aab805101fe221 > +libtool-cross-2.4.2-r3.1.do_fetch > +libtool-cross-2.4.2-r3.1.do_fetch.sigdata.79da02e9de369c7964c9b54e291088d5 > +libtool-cross-2.4.2-r3.1.do_install > +libtool-cross-2.4.2-r3.1.do_install.sigdata.607177b917d48c411c6c2fbaf475867b > +libtool-cross-2.4.2-r3.1.do_package.am335x-evm > +libtool-cross-2.4.2-r3.1.do_package.sigdata.4f0eb910d74ff36b564968e09a8e15f2 > +libtool-cross-2.4.2-r3.1.do_package_write > +libtool-cross-2.4.2-r3.1.do_package_write_ipk > +libtool-cross-2.4.2-r3.1.do_package_write_ipk.sigdata.0cc36358a4c5dee1f612fe3a90c60b1a > +libtool-cross-2.4.2-r3.1.do_patch > +libtool-cross-2.4.2-r3.1.do_patch.sigdata.a319c3ae77229a7558409abc179ea99d > +libtool-cross-2.4.2-r3.1.do_populate_lic > +libtool-cross-2.4.2-r3.1.do_populate_lic.sigdata.82a19386b4380a0077d2b55f8934851a > +libtool-cross-2.4.2-r3.1.do_populate_sysroot.am335x-evm > +libtool-cross-2.4.2-r3.1.do_populate_sysroot.sigdata.8c61b5566945f9a439faa916d70a9fd0 > +libtool-cross-2.4.2-r3.1.do_unpack > +libtool-cross-2.4.2-r3.1.do_unpack.sigdata.322a15e21f6df957f5ba116da19d5585 > linux-libc-headers-3.2-r1.do_compile > linux-libc-headers-3.2-r1.do_compile.sigdata.6047c862356fa8f3a56269daf2cde26b > linux-libc-headers-3.2-r1.do_configure > > Notice that the only stamps for steps done between a passing and failing > build are for the libtool-cross, as well as the steps after the do_configure > step of libtool since it
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On > Behalf Of Maupin, Chase > Sent: Thursday, October 04, 2012 8:02 AM > To: Richard Purdie > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > > -Original Message- > > From: Richard Purdie > [mailto:richard.pur...@linuxfoundation.org] > > Sent: Thursday, October 04, 2012 7:58 AM > > To: Maupin, Chase > > Cc: openembedded-core@lists.openembedded.org > > Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on > > libtool-cross > > > > On Thu, 2012-10-04 at 12:39 +, Maupin, Chase wrote: > > > I was able to reproduce this consistently on my build server > > which has > > > 24 cores running at 3.5 GHz. I was using: > > > > > > BB_NUMBER_THREADS = "24" > > > > > > And > > > > > > PARALLEL_MAKE = "-j 24" > > > > > > I can try a build reducing the number of threads and see if > the > > issue > > > goes away as this might be a difference between our builds. > > Can you > > > tell me what you are using? > > > > I tested this with 48/48 in master. > > > > > It seemed like a race condition because after I got the error > I > > was > > > able to do a -c cleanall of libtool and kick off the build > > again once > > > libtool-cross was built and it would pass. Likewise I did: > > > > > > bitbake libtool-cross > > > bitbake libtool > > > > > > and that would work but just > > > > > > bitbake libtool > > > > > > would fail. > > > > "bitbake libtool" works here quite consistently. I therefore > > don't want > > to add this dependency until we figure out exactly what is > racing > > against what or have a better understanding of why this is > > failing. > > Something doesn't seem right as if your premise of a missing > > dependency > > is correct, the above wouldn't work. > > Understood. Let me look closer. My build setup is an Ubuntu > 10.04 system and I'm using an external Arago toolchain as well. > On my setup I can consistently cause this to fail even with a > lower number of threads. So perhaps the issue is not the > libtool-cross dependency, but that libtool-cross itself forces > something else to be built first. Thanks for the information on > your setup and confirmation that you do not see this issue. I tried the following to help narrow this down. Please let me know if there is something else I could try to help narrow the issue. I ran: bitbake -c cleanall libtool bitbake libtool Each time it failed I would get a list of the contents of the work directory and the stamps directory. My goal here was to be able to find what changed between a pass and a fail. I kept running the test above until I had a consistent failure, and there were no new packages being added into my work directory and no new stamps being created. Basically this told me that all the packages that were going to be built from doing "bitbake libtool" were built and that the only package being built was libtool itself. I then changed my build steps to do: bitbake -c cleanall libtool bitbake libtool-cross bitbake libtool This passed on the first run. I captured the same work directory contents and stamps contents and then did a diff to see what had changed between these builds. The diffs were: For Stamps diff libtool-failed-stamps libtool-passed-stamps --- /arago-tmp-eglibc/stamps$ diff -burpN libtool-failed-stamps libtool-passed-stamps --- libtool-failed-stamps 2012-10-04 09:11:27.909881710 -0500 +++ libtool-passed-stamps 2012-10-04 09:14:33.997328844 -0500 @@ -23,18 +23,56 @@ external-arago-toolchain-1.0-r2.do_popul external-arago-toolchain-1.0-r2.do_populate_sysroot.sigdata.bccac35b2b6fecd3cbec49ccc208c6a9 external-arago-toolchain-1.0-r2.do_unpack external-arago-toolchain-1.0-r2.do_unpack.sigdata.14d8090b51a447ceb4ccf44941781e47 +libtool-2.4.2-r3.0.do_build libtool-2.4.2-r3.0.do_cleansstate libtool-2.4.2-r3.0.do_cleansstate.sigdata.e2a5d5c89e3be41823e835c18b50dfa3 +libtool-2.4.2-r3.0.do_compile +libtool-2.4.2-r3.0.do_compile.sigdata.ea5125c6ecc524aed598dba3b731d92d +libtool-2.4.2-r3.0.do_configure +libtool-2.4.2-r3.0.do_configure.sigdata.2e462cacc7c699c75bce74bb7dcf55f4 libtool-2.4.2-r3.0.do_create_srcipk libtool-2.4.2-r3.0.do_create_srcipk.sigdata.caa56f6b8b195ff4e6a063f1288c5f86 libtool-2.4.2-r3.0.do_fetch libtool-2.4.2-r3.0.do_fetch.sigdata.0ccdbfe0aace02237038ae0203de9060 +libtool-2.4.2-r3.0.do_install +libtool-2.4.2-r3.0.do_install.sigdata.9ad203ae762fe0556e7a991ab8a7707c +libtool-2.4.2-r3.0.do_package.am335x-evm +libtool-2.4.2-r3.0.do_package.sigdata.ffb4b811e7643d5f37afbcffef84f5e8 +libtool-2.4.2-r3.0.do_package_write +libtool-2.4.2-r3.0.do_package_write_ipk +libtool-2.4.2-r3.0.do_package_write_ipk.sigdata.eb16601f7f4f1afbfabc8542fea3af30 libtool-2.4.2-r3.0.do_patch libtool-2.4.2-r3.0.do_p
[OE-core] [oe-core][PATCH 7/7] scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs
* it's not very universal, but works with default oe-core setup and
shows basic HOW-TO, because many people still don't know how to detect
machine specific sstate checksums
* someone can improve this with bitbake -e calls to detect BASE and to
specify MACHINEs and TARGETs in parameter instead of hardcoded values
in script..
Signed-off-by: Martin Jansa
---
scripts/sstate-diff.sh | 32
1 file changed, 32 insertions(+)
create mode 100755 scripts/sstate-diff.sh
diff --git a/scripts/sstate-diff.sh b/scripts/sstate-diff.sh
new file mode 100755
index 000..2d256e8
--- /dev/null
+++ b/scripts/sstate-diff.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+# Used to compare sstate checksums between MACHINES
+# Update MACHINES, TARGETS and BASE
+# Execute script and compare generated list.M files
+
+# $ diff stamps.1349348392/fake-cortexa8/list.M
stamps.1349348392/fake-cortexa9/list.M | wc -l
+# 538
+
+# Then to compare sigdata use something like:
+# $ ls stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure*
+#
stamps.1349348392/fake-cortexa8/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.cb73b3630a7b8191e72fc469c5137025
+#
stamps.1349348392/fake-cortexa9/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.f37ada177bf99ce8af85914df22b5a0b
+# $ bitbake-diffsigs
stamps.1349348392/*/armv7a-vfp-neon*/linux-libc*do_configure*
+# basehash changed from 8d0bd67bb1da6f68717760fc3ef43171 to
e869fa61426e88e9c30726ba88a1216a
+# Variable TUNE_CCARGS value changed from -march=armv7-a
-mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 to
-march=armv7-a -mthumb-interwork -mfloat-abi=softfp -mfpu=neon
-mtune=cortex-a9
+
+MACHINES="fake-arm1136jf-s fake-arm920t fake-arm926ejs fake-arm9tdmi
fake-cortexa8 fake-cortexa9 fake-cortexm1 fake-cortexm3 fake-cortexr4
fake-ep9312 fake-iwmmxt fake-strongarm1100 fake-xscale"
+TARGETS="dhcp"
+
+BASE="/OE/oe-core"
+OUTPUT=${BASE}/stamps.`date "+%s"`
+
+for M in ${MACHINES}; do
+ find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f
+ mkdir -p ${OUTPUT}/${M}
+ export MACHINE=${M}; bitbake -S ${TARGETS} | tee -a ${OUTPUT}/${M}/log;
+ cp -ra ${BASE}/tmp-eglibc/stamps/* ${OUTPUT}/${M}
+ find ${OUTPUT}/${M} -name \*sigdata\* | sed "s#${OUTPUT}/${M}/##g" | sort >
${OUTPUT}/${M}/list
+ sed "s/om_gta0/om-gta0/g; s/${M}/MACHINE/g" ${OUTPUT}/${M}/list | sort >
${OUTPUT}/${M}/list.M
+ find ${BASE}/tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f
+done
--
1.7.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 6/7] tune-*: define more generic DEFAULTTUNE to share feed between machines
* this is mostly for backwards compatibility and to share binary feed like it was before, but now without missing different -mtune in it * if you want to build some package with -mtune add something like this to your distro config DEFAULTTUNE_qemuarm_pn-openssl = "arm926ejs" DEFAULTTUNE_qemuarmx_pn-openssl = "xscale" be aware that if you do this you should do it also for all packages which depends on openssl because if you dont and you build e.g. dhcp, then dhcp build for arm926ejs (even with DEFAULTTUNE armv5te) will depend on openssl with arm926ejs, so dhcp in armv5te feed will be rebuild after each MACHINE switch. * cortexm3, cortexr4, iwmmx and ep9312 are using own DEFAULTTUNE because they define also different -march * shared feeds are armv4t: arm920t, arm9tdmi armv5te: arm926ejs, xscale armv7a-neon: cortexa8, cortexa9 Signed-off-by: Martin Jansa --- meta/conf/machine/include/tune-arm1136jf-s.inc | 2 +- meta/conf/machine/include/tune-arm920t.inc | 2 +- meta/conf/machine/include/tune-arm926ejs.inc | 2 +- meta/conf/machine/include/tune-arm9tdmi.inc | 2 +- meta/conf/machine/include/tune-cortexa8.inc | 2 +- meta/conf/machine/include/tune-cortexa9.inc | 2 +- meta/conf/machine/include/tune-cortexm1.inc | 2 +- meta/conf/machine/include/tune-strongarm1100.inc | 2 +- meta/conf/machine/include/tune-xscale.inc| 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc index 2efcedd..adece48 100644 --- a/meta/conf/machine/include/tune-arm1136jf-s.inc +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm1136jfs" +DEFAULTTUNE ?= "armv6" require conf/machine/include/arm/arch-armv6.inc diff --git a/meta/conf/machine/include/tune-arm920t.inc b/meta/conf/machine/include/tune-arm920t.inc index 459d978..3240fa8 100644 --- a/meta/conf/machine/include/tune-arm920t.inc +++ b/meta/conf/machine/include/tune-arm920t.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm920t" +DEFAULTTUNE ?= "armv4t" require conf/machine/include/arm/arch-armv4.inc diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc index 0cfeb77..301a3c2 100644 --- a/meta/conf/machine/include/tune-arm926ejs.inc +++ b/meta/conf/machine/include/tune-arm926ejs.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm926ejs" +DEFAULTTUNE ?= "armv5te" require conf/machine/include/arm/arch-armv5-dsp.inc diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc b/meta/conf/machine/include/tune-arm9tdmi.inc index 100242f..a981a65 100644 --- a/meta/conf/machine/include/tune-arm9tdmi.inc +++ b/meta/conf/machine/include/tune-arm9tdmi.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "arm9tdmi" +DEFAULTTUNE ?= "armv4t" require conf/machine/include/arm/arch-armv4.inc diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc index 29fbe89..89878d4 100644 --- a/meta/conf/machine/include/tune-cortexa8.inc +++ b/meta/conf/machine/include/tune-cortexa8.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexa8-neon" +DEFAULTTUNE ?= "armv7a-neon" require conf/machine/include/arm/arch-armv7a.inc diff --git a/meta/conf/machine/include/tune-cortexa9.inc b/meta/conf/machine/include/tune-cortexa9.inc index e2f78d3..addfdad 100644 --- a/meta/conf/machine/include/tune-cortexa9.inc +++ b/meta/conf/machine/include/tune-cortexa9.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexa9-neon" +DEFAULTTUNE ?= "armv7a-neon" require conf/machine/include/arm/arch-armv7a.inc diff --git a/meta/conf/machine/include/tune-cortexm1.inc b/meta/conf/machine/include/tune-cortexm1.inc index ba3cbe9..c4c658b 100644 --- a/meta/conf/machine/include/tune-cortexm1.inc +++ b/meta/conf/machine/include/tune-cortexm1.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "cortexm1" +DEFAULTTUNE ?= "armv7a" require conf/machine/include/arm/arch-armv7a.inc diff --git a/meta/conf/machine/include/tune-strongarm1100.inc b/meta/conf/machine/include/tune-strongarm1100.inc index 3beaaed..fba0a1b 100644 --- a/meta/conf/machine/include/tune-strongarm1100.inc +++ b/meta/conf/machine/include/tune-strongarm1100.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "strongarm" +DEFAULTTUNE ?= "armv4" require conf/machine/include/arm/arch-armv4.inc diff --git a/meta/conf/machine/include/tune-xscale.inc b/meta/conf/machine/include/tune-xscale.inc index d9925eb..a48c2d9 100644 --- a/meta/conf/machine/include/tune-xscale.inc +++ b/meta/conf/machine/include/tune-xscale.inc @@ -1,4 +1,4 @@ -DEFAULTTUNE ?= "xscale" +DEFAULTTUNE ?= "armv5te" require conf/machine/include/arm/arch-armv5-dsp.inc -- 1.7.12 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 5/7] arch-arm: define different ARMPKGARCH when different CCARGS are used
* without this tune-xscale and tune-arm926ejs were both creating
packages in armv5te feed, but each with different -mtune, with
OEBasicHash enabled it was causing each package to rebuild with new
-mtune after MACHINE switch, but that doesn't make sense with output
stored in the same armv5te feed
* this makes different feed for each -mtune, but more generic one to be
selected with DEFAULTTUNE
* tune-iwmmxt and tune-ep9312 were already using this, just move it
bellow AVAILTUNES and use ARMPKGARCH_tune-foo syntax
* tune-cortexr4 and tune-cortexm3 are using armv7r/armv7m as ARMPKGARCH
because there isn't another tune to use the same -march
* Fixes [YOCTO #3219]
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/tune-arm1136jf-s.inc | 1 +
meta/conf/machine/include/tune-arm920t.inc | 1 +
meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
meta/conf/machine/include/tune-arm9tdmi.inc | 1 +
meta/conf/machine/include/tune-cortexa8.inc | 6 ++
meta/conf/machine/include/tune-cortexa9.inc | 6 ++
meta/conf/machine/include/tune-cortexm1.inc | 1 +
meta/conf/machine/include/tune-cortexm3.inc | 2 +-
meta/conf/machine/include/tune-cortexr4.inc | 2 +-
meta/conf/machine/include/tune-ep9312.inc| 4 +---
meta/conf/machine/include/tune-iwmmxt.inc| 4 +---
meta/conf/machine/include/tune-strongarm1100.inc | 1 +
meta/conf/machine/include/tune-xscale.inc| 2 ++
13 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index 4f4a2eb..2efcedd 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -6,5 +6,6 @@ TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor
optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs",
"-mtune=arm1136jf-s", "", d)}"
AVAILTUNES += "arm1136jfs"
+ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
diff --git a/meta/conf/machine/include/tune-arm920t.inc
b/meta/conf/machine/include/tune-arm920t.inc
index b7584ab..459d978 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -6,6 +6,7 @@ TUNEVALID[arm920t] = "Enable arm920t specific processor
optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t",
"-mtune=arm920t", "", d)}"
AVAILTUNES += "arm920t"
+ARMPKGARCH_tune-arm920t = "arm920t"
TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc
b/meta/conf/machine/include/tune-arm926ejs.inc
index 7f2cc4e..0cfeb77 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -6,6 +6,6 @@ TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor
optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
"-mtune=arm926ej-s", "", d)}"
AVAILTUNES += "arm926ejs"
+ARMPKGARCH_tune-arm926ejs = "arm926ejs"
TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
-
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc
b/meta/conf/machine/include/tune-arm9tdmi.inc
index 0dc5c26..100242f 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -6,6 +6,7 @@ TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor
optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi",
"-mtune=arm9tdmi", "", d)}"
AVAILTUNES += "arm9tdmi"
+ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"
TUNE_FEATURES_tune-arm9tdmi = "${TUNE_FEATURES_tune-armv4t} arm9tdmi"
PACKAGE_EXTRA_ARCHS_tune-arm9tdmi = "${PACKAGE_EXTRA_ARCHS_tune-armv4t}"
diff --git a/meta/conf/machine/include/tune-cortexa8.inc
b/meta/conf/machine/include/tune-cortexa8.inc
index 9d79a58..29fbe89 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -7,6 +7,9 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES",
"cortexa8", "-mtune=cortex
# Little Endian base configs
AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon"
+ARMPKGARCH_tune-cortexa8 = "cortexa8"
+ARMPKGARCH_tune-cortexa8t = "cortexa8t"
+ARMPKGARCH_tune-cortexa8-neon = "cortexa8-neon"
TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8"
TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8"
TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-armv7a-neon} cortexa8"
@@ -16,6 +19,9 @@ PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon
# VFP Tunes
AVAILTUNES += "cortexa8hf co
[OE-core] [oe-core][PATCH 4/7] arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes
* tune-foo is not valid override, for it to work I had to add
ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
but that doesn't work without value defined for every supported
DEFAULTTUNE value, otherwise it's expanded like this
TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/arm/arch-arm.inc | 2 +-
meta/conf/machine/include/arm/arch-armv4.inc | 6 --
meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12
meta/conf/machine/include/arm/arch-armv5.inc | 14 --
meta/conf/machine/include/arm/arch-armv6.inc | 10 --
meta/conf/machine/include/arm/arch-armv7a.inc| 18 --
6 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/meta/conf/machine/include/arm/arch-arm.inc
b/meta/conf/machine/include/arm/arch-arm.inc
index da51044..90b80c4 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -1,7 +1,7 @@
TUNEVALID[bigendian] = "Enable big-endian mode."
-ARMPKGARCH ??= "arm"
+ARMPKGARCH = "${ARMPKGARCH_tune-${DEFAULTTUNE}}"
ARMPKGSFX_ENDIAN = "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "b",
"", d)}"
ARMPKGSFX_FPU ??= ""
ARMPKGSFX_DSP ??= ""
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc
b/meta/conf/machine/include/arm/arch-armv4.inc
index cb747ac..07e8eec 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -1,7 +1,5 @@
DEFAULTTUNE ?= "armv4"
-ARMPKGARCH ?= "armv4"
-
TUNEVALID[armv4] = "Enable instructions for ARMv4"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4",
"-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
TARGET_LD_KERNEL_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "armv4",
"--fix-v4bx", "", d)}"
@@ -12,6 +10,8 @@ require conf/machine/include/arm/feature-arm-thumb.inc
# Little Endian
AVAILTUNES += "armv4 armv4t"
+ARMPKGARCH_tune-armv4 ?= "armv4"
+ARMPKGARCH_tune-armv4t ?= "armv4"
TUNE_FEATURES_tune-armv4 ?= "armv4"
TUNE_FEATURES_tune-armv4t ?= "armv4 thumb"
PACKAGE_EXTRA_ARCHS_tune-armv4 = "arm armv4"
@@ -19,6 +19,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv4t =
"${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4t"
# Big Endian
AVAILTUNES += "armv4b armv4tb"
+ARMPKGARCH_tune-armv4b ?= "armv4"
+ARMPKGARCH_tune-armv4tb ?= "armv4"
TUNE_FEATURES_tune-armv4b ?= "${TUNE_FEATURES_tune-armv4} bigendian"
TUNE_FEATURES_tune-armv4tb ?= "${TUNE_FEATURES_tune-armv4t} bigendian"
PACKAGE_EXTRA_ARCHS_tune-armv4b = "armeb armv4b"
diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index 0f64562..0ae6411 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -5,6 +5,8 @@ require conf/machine/include/arm/arch-armv5.inc
# Little Endian
AVAILTUNES += "armv5e armv5te"
+ARMPKGARCH_tune-armv5e ?= "armv5"
+ARMPKGARCH_tune-armv5te ?= "armv5"
TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
@@ -12,6 +14,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5te =
"${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e ar
# Little Endian + VFP/DSP
AVAILTUNES += "armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp"
+ARMPKGARCH_tune-armv5e-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5te-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5ehf-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5tehf-vfp ?= "armv5"
TUNE_FEATURES_tune-armv5e-vfp ?= "armv5 vfp dsp"
TUNE_FEATURES_tune-armv5te-vfp ?= "armv5 vfp dsp thumb"
TUNE_FEATURES_tune-armv5ehf-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp}
callconvention-hard"
@@ -23,6 +29,8 @@ PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp =
"${PACKAGE_EXTRA_ARCHS_tune-armv5thf-vf
# Big Endian
AVAILTUNES += "armv5eb armv5teb"
+ARMPKGARCH_tune-armv5eb ?= "armv5"
+ARMPKGARCH_tune-armv5teb ?= "armv5"
TUNE_FEATURES_tune-armv5eb ?= "${TUNE_FEATURES_tune-armv5e} bigendian"
TUNE_FEATURES_tune-armv5teb ?= "${TUNE_FEATURES_tune-armv5te} bigendian"
PACKAGE_EXTRA_ARCHS_tune-armv5eb = "${PACKAGE_EXTRA_ARCHS_tune-armv5b} armv5eb"
@@ -30,6 +38,10 @@ PACKAGE_EXTRA_ARCHS_tune-armv5teb =
"${PACKAGE_EXTRA_ARCHS_tune-armv5tb} armv5eb
# Big Endian + VFP/DSP
AVAILTUNES += "armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp"
+ARMPKGARCH_tune-armv5eb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5teb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5ehfb-vfp ?= "armv5"
+ARMPKGARCH_tune-armv5tehfb-vfp ?= "armv5"
TUNE_FEATURES_tune-armv5eb-vfp ?= "${TUNE_FEATURES_tune-armv5e-vfp} bigendian"
TUNE_FEATURES_tune-armv5teb-vfp ?= "${TUNE_FEATURES_tune-armv5te-vfp}
bigendian"
TUNE_FEATURES_tune-armv5ehfb-vfp ?= "${TUNE_FEATURES_tune-armv5eb-vfp}
callconvention-hard"
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc
b/meta/conf/machine/include/arm/arch-armv5.inc
index 98780e5..5ed56bc 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/ma
[OE-core] [oe-core][PATCH 3/7] tune-cortexr4: fix march value
* probably copy&paste error from tune-cortexm3.conf
commit 789dcb8e68a2ab9784ac10ab36815010c61af2fc
Author: Richard Purdie
Date: Mon Jul 25 19:03:24 2011 +0100
Add ARM tune file overhaul based largely on work from Mark Hatle
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/tune-cortexr4.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-cortexr4.inc
b/meta/conf/machine/include/tune-cortexr4.inc
index d1fc607..c8c2bfb 100644
--- a/meta/conf/machine/include/tune-cortexr4.inc
+++ b/meta/conf/machine/include/tune-cortexr4.inc
@@ -7,7 +7,7 @@ TUNEVALID[cortexr4] = "Enable Cortex-R4 specific processor
optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexr4",
"-mtune=cortex-r4", "", d)}"
TUNEVALID[armv7r] = "Enable Cortex-R4 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
"-march=armv7-m", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7r",
"-march=armv7-r", "", d)}"
AVAILTUNES += "cortexr4"
TUNE_FEATURES_tune-cortexr4 = "armv7r vfp cortexr4"
--
1.7.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 2/7] bitbake.conf: add TUNE_CCARGS[vardepvalue]
* we don't care about expression but value
* e.g. tune-xscale and tune-arm926ejs have different expression
in TUNE_CCARGS but with the same DEFAULTTUNE the result is the same
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030032.html
Signed-off-by: Martin Jansa
---
meta/conf/bitbake.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5cb5b13..fa8fb5e 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -98,6 +98,7 @@ HOST_EXEEXT = ""
TUNE_ARCH ??= "INVALID"
TUNE_CCARGS ??= ""
+TUNE_CCARGS[vardepvalue] = "${TUNE_CCARGS}"
TUNE_LDARGS ??= ""
TUNE_ASARGS ??= ""
TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
--
1.7.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 1/7] tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES
* without this you'll get different sstate checksum for webkit-gtk and
cairo even when you build them with DEFAULTTUNE == armv5te
* maybe this isn't needed at all anymore or if it is then it should be
applied in arm-armv5.inc for all armv5te devices, not only xscale?
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/tune-xscale.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/machine/include/tune-xscale.inc
b/meta/conf/machine/include/tune-xscale.inc
index 80a3683..0d5d060 100644
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -15,5 +15,5 @@ PACKAGE_EXTRA_ARCHS_tune-xscale-be =
"${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
# webkit-gtk has alignment issues with double instructions on armv5 so
# disable them here
-TUNE_CCARGS_pn-webkit-gtk = "-march=armv4t"
-TUNE_CCARGS_pn-cairo = "-march=armv4t"
+TUNE_CCARGS_pn-webkit-gtk = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
"-march=armv4t", "", d)}"
+TUNE_CCARGS_pn-cairo = "${@bb.utils.contains("TUNE_FEATURES", "xscale",
"-march=armv4t", "", d)}"
--
1.7.12
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 0/7] conf/machine: fix arm tune files
Tested with sstate-diff.sh script and fake machine configs added in this branch: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test Fixes [YOCTO #3219] The following changes since commit df2b756436b90f8f9ff229ba64d0af30d9d4f923: common-licenses: Adding bzip (2012-10-04 14:09:06 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/tune2 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/tune2 Martin Jansa (7): tune-xscale: replace TUNE_CCARGS for webkit-gtk and cairo only with xscale in TUNE_FEATURES bitbake.conf: add TUNE_CCARGS[vardepvalue] tune-cortexr4: fix march value arm/arch-arm*: define ARMPKGARCH_tune-* for default tunes arch-arm: define different ARMPKGARCH when different CCARGS are used tune-*: define more generic DEFAULTTUNE to share feed between machines scripts/sstate-diff.sh: add simple script to compare sstate checksums between MACHINEs meta/conf/bitbake.conf | 1 + meta/conf/machine/include/arm/arch-arm.inc | 2 +- meta/conf/machine/include/arm/arch-armv4.inc | 6 +++-- meta/conf/machine/include/arm/arch-armv5-dsp.inc | 12 + meta/conf/machine/include/arm/arch-armv5.inc | 14 +-- meta/conf/machine/include/arm/arch-armv6.inc | 10 ++-- meta/conf/machine/include/arm/arch-armv7a.inc| 18 +++-- meta/conf/machine/include/tune-arm1136jf-s.inc | 3 ++- meta/conf/machine/include/tune-arm920t.inc | 3 ++- meta/conf/machine/include/tune-arm926ejs.inc | 4 +-- meta/conf/machine/include/tune-arm9tdmi.inc | 3 ++- meta/conf/machine/include/tune-cortexa8.inc | 8 +- meta/conf/machine/include/tune-cortexa9.inc | 8 +- meta/conf/machine/include/tune-cortexm1.inc | 3 ++- meta/conf/machine/include/tune-cortexm3.inc | 2 +- meta/conf/machine/include/tune-cortexr4.inc | 4 +-- meta/conf/machine/include/tune-ep9312.inc| 4 +-- meta/conf/machine/include/tune-iwmmxt.inc| 4 +-- meta/conf/machine/include/tune-strongarm1100.inc | 3 ++- meta/conf/machine/include/tune-xscale.inc| 8 +++--- scripts/sstate-diff.sh | 32 21 files changed, 122 insertions(+), 30 deletions(-) create mode 100755 scripts/sstate-diff.sh -- 1.7.12 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
> -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Thursday, October 04, 2012 7:58 AM > To: Maupin, Chase > Cc: openembedded-core@lists.openembedded.org > Subject: RE: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > On Thu, 2012-10-04 at 12:39 +, Maupin, Chase wrote: > > I was able to reproduce this consistently on my build server > which has > > 24 cores running at 3.5 GHz. I was using: > > > > BB_NUMBER_THREADS = "24" > > > > And > > > > PARALLEL_MAKE = "-j 24" > > > > I can try a build reducing the number of threads and see if the > issue > > goes away as this might be a difference between our builds. > Can you > > tell me what you are using? > > I tested this with 48/48 in master. > > > It seemed like a race condition because after I got the error I > was > > able to do a -c cleanall of libtool and kick off the build > again once > > libtool-cross was built and it would pass. Likewise I did: > > > > bitbake libtool-cross > > bitbake libtool > > > > and that would work but just > > > > bitbake libtool > > > > would fail. > > "bitbake libtool" works here quite consistently. I therefore > don't want > to add this dependency until we figure out exactly what is racing > against what or have a better understanding of why this is > failing. > Something doesn't seem right as if your premise of a missing > dependency > is correct, the above wouldn't work. Understood. Let me look closer. My build setup is an Ubuntu 10.04 system and I'm using an external Arago toolchain as well. On my setup I can consistently cause this to fail even with a lower number of threads. So perhaps the issue is not the libtool-cross dependency, but that libtool-cross itself forces something else to be built first. Thanks for the information on your setup and confirmation that you do not see this issue. > > Cheers, > > Richard > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
On Thu, 2012-10-04 at 12:39 +, Maupin, Chase wrote: > I was able to reproduce this consistently on my build server which has > 24 cores running at 3.5 GHz. I was using: > > BB_NUMBER_THREADS = "24" > > And > > PARALLEL_MAKE = "-j 24" > > I can try a build reducing the number of threads and see if the issue > goes away as this might be a difference between our builds. Can you > tell me what you are using? I tested this with 48/48 in master. > It seemed like a race condition because after I got the error I was > able to do a -c cleanall of libtool and kick off the build again once > libtool-cross was built and it would pass. Likewise I did: > > bitbake libtool-cross > bitbake libtool > > and that would work but just > > bitbake libtool > > would fail. "bitbake libtool" works here quite consistently. I therefore don't want to add this dependency until we figure out exactly what is racing against what or have a better understanding of why this is failing. Something doesn't seem right as if your premise of a missing dependency is correct, the above wouldn't work. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Only one copy of bitbake should be run against a build directory
On Thu, 2012-10-04 at 13:07 +0100, Phil Blundell wrote: > Since updating my copy of bitbake to one which does this extra locking, > I've come to realise that the constraint of having only one copy of > bitbake running is a bit of a nuisance when making use of devshells. I > used to quite often have one or two long-running devshells for packages > that I was actively working on, and then in parallel with that would use > bitbake to recompile other things. With the new locking mechanism, as > soon as I have a single devshell open I am now prohibited from using > bitbake for anything else in that same build directory. > > Would it be reasonable to exempt devshells from that locking or is there > some compelling reason why they need to be serialised? The reason it was added was that there were too many people shooting themselves in the foot with multiple bitbake processes running without them realising it. I has "saved" me a few times too. I'm not sure how you'd allow devshell but not anything else, particularly as there may be tasks that run before the devshell task gets executed. I'd be fine with a --ignore-the-lockfile-I-know-what-I-am-doing type option, then on your own head be it ;-). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On > Behalf Of Richard Purdie > Sent: Thursday, October 04, 2012 4:21 AM > To: Maupin, Chase > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on > libtool-cross > > On Tue, 2012-10-02 at 16:30 -0500, Chase Maupin wrote: > > * When building with 24 bitbake threads on my system I observed > > errors like the following: > > | configure.ac:199: error: LT_LANG: unsupported language: > "Go" > > | /work/armv7a-vfp-neon-oe-linux-gnueabi/libtool- > 2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768: LT_LANG is > expanded from... > > | configure.ac:199: the top level > > | autom4te: m4 failed with exit status: 1 > > * This could be found by doing a clean build. If a build had > > already been performed then often just cleaning the libtool > > package and rebuilding it would resolve the issue. > > * Adding a DEPENDS on libtool-cross resolves this issue with a > > clean build. > > * Bump the PR > > So how do I reproduce this bug? In theory I'd just run "bitbake > libtool" > in a clean build directory? > > I've tried that with master and it all works? :/ Richard, I was able to reproduce this consistently on my build server which has 24 cores running at 3.5 GHz. I was using: BB_NUMBER_THREADS = "24" And PARALLEL_MAKE = "-j 24" I can try a build reducing the number of threads and see if the issue goes away as this might be a difference between our builds. Can you tell me what you are using? It seemed like a race condition because after I got the error I was able to do a -c cleanall of libtool and kick off the build again once libtool-cross was built and it would pass. Likewise I did: bitbake libtool-cross bitbake libtool and that would work but just bitbake libtool would fail. > > Cheers, > > Richard > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded- > core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Only one copy of bitbake should be run against a build directory
At 13:07, Thu 2012-10-04, Phil Blundell wrote: > Since updating my copy of bitbake to one which does this extra locking, > I've come to realise that the constraint of having only one copy of > bitbake running is a bit of a nuisance when making use of devshells. In Message-ID: <20120924074452.gh2...@kattastrofe.rd.tandberg.com>, Subject: [OE-core] Customize devshell terminal command / environment, I suggested the patch found in https://gist.github.com/3774736 This patch would allow you to customize the terminal used, including spawning a terminal that detaches itself from the bitbake. So, my setup is: patch plus bitbake running in a screen instance plus these settings: OE_TERMINAL = "custom" OE_TERMINAL_CUSTOMCMD = "screen" OE_TERMINAL_EXPORTS += "STY" (Should I submit this (non-obtrusive) patch somewhere? (-: ) Smiles, -- Morten Minde Neergaard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Only one copy of bitbake should be run against a build directory
On Thu, Oct 04, 2012 at 01:07:46PM +0100, Phil Blundell wrote: > Since updating my copy of bitbake to one which does this extra locking, > I've come to realise that the constraint of having only one copy of > bitbake running is a bit of a nuisance when making use of devshells. I > used to quite often have one or two long-running devshells for packages > that I was actively working on, and then in parallel with that would use > bitbake to recompile other things. With the new locking mechanism, as > soon as I have a single devshell open I am now prohibited from using > bitbake for anything else in that same build directory. > > Would it be reasonable to exempt devshells from that locking or is there > some compelling reason why they need to be serialised? The same does apply to bitbake-diffsigs now after IIRC this patch http://git.openembedded.org/bitbake/commit/?id=cc70181659c07e04c205e17832846acf1ff31d28 before that I could use bitbake-diffsigs from any directory (not only TOPDIR) and also when build in the same directory was still running. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Only one copy of bitbake should be run against a build directory
Since updating my copy of bitbake to one which does this extra locking, I've come to realise that the constraint of having only one copy of bitbake running is a bit of a nuisance when making use of devshells. I used to quite often have one or two long-running devshells for packages that I was actively working on, and then in parallel with that would use bitbake to recompile other things. With the new locking mechanism, as soon as I have a single devshell open I am now prohibited from using bitbake for anything else in that same build directory. Would it be reasonable to exempt devshells from that locking or is there some compelling reason why they need to be serialised? thanks p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] shutdown-desktop: ensure the postinst script succeeds
When the hostname isn't qemuarm the grep fails so the postinst fails. Stop this
happening by explicitly evaluating true.
[YOCTO #3224]
Signed-off-by: Ross Burton
---
meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb
b/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb
index d0f507e..c5096c1 100644
--- a/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb
+++ b/meta/recipes-sato/shutdown-desktop/shutdown-desktop.bb
@@ -5,6 +5,8 @@ LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3
SRC_URI = "file://shutdown.desktop"
+PR = "r1"
+
S = "${WORKDIR}"
do_install() {
@@ -14,7 +16,8 @@ do_install() {
pkg_postinst_${PN} () {
grep -q qemuarm $D${sysconfdir}/hostname && \
-sed -i $D${datadir}/applications/shutdown.desktop -e
's/^Exec=halt/Exec=reboot/'
+sed -i $D${datadir}/applications/shutdown.desktop -e
's/^Exec=halt/Exec=reboot/' \
+|| true
}
inherit allarch
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sato-icon-theme: use gtk-icon-cache helper class
Instead of explicitly updating the icon cache use the helper class that also
forces a loader update at the same time. This eliminates the possibility of
updating the icon cache without any gdk-pixbuf loaders.
Also check that the Sato icon theme isn't already set to avoid appending to the
file every time the postinst runs.
[YOCTO #2399]
Signed-off-by: Ross Burton
---
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc | 15 +++
.../sato-icon-theme/sato-icon-theme_0.4.1.bb|2 +-
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
index 9fd1012..0bd4814 100644
--- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
+++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
@@ -8,18 +8,17 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=56a830bbe6e4697fe6cbbae01bb7c2b2"
SECTION = "x11"
DEPENDS = ""
-inherit autotools pkgconfig allarch
+inherit autotools pkgconfig allarch gtk-icon-cache
FILES_${PN} += "${datadir}"
EXTRA_OECONF +=
"--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping"
-#explictly setting "Sato" as default icon theme to avoid icon missing due to
-#tricky race condition
+# Explictly setting "Sato" as the default icon theme to avoid flickering from
+# the desktop and settings daemon racing. This shouldn't be done here but in
the sato image
pkg_postinst_${PN} () {
-if [ "x$D" != "x" ]; then
-exit 1
-fi
-gtk-update-icon-cache -q /usr/share/icons/Sato
-echo 'gtk-icon-theme-name = "Sato"' >> /etc/gtk-2.0/gtkrc
+mkdir -p $D/etc/gtk-2.0
+
+grep -s -q -e ^gtk-icon-theme-name.*\"Sato\" $D/etc/gtk-2.0/gtkrc || \
+echo 'gtk-icon-theme-name = "Sato"' >> $D/etc/gtk-2.0/gtkrc
}
diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
index 108f8e8..6405359 100644
--- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
+++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
@@ -2,7 +2,7 @@ require sato-icon-theme.inc
DEPENDS += "icon-naming-utils-native"
-PR = "r3"
+PR = "r4"
SRC_URI = "http://pokylinux.org/releases/sato/${BPN}-${PV}.tar.gz \
file://iconpath-option.patch \
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Purdie : bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
On Thu, 2012-10-04 at 11:33 +0200, Martin Jansa wrote: > On Thu, Oct 04, 2012 at 10:28:35AM +0100, Richard Purdie wrote: > > On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote: > > > On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote: > > > > Module: openembedded-core.git > > > > Branch: master > > > > Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a > > > > URL: > > > > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a > > > > > > > > Author: Richard Purdie > > > > Date: Tue Oct 2 14:12:21 2012 +0100 > > > > > > > > bitbake.conf: Add chrpath-native to ASSUME_PROVIDED > > > > > > > > We assume chrpath is provided natively so it should be listed in > > > > ASSUME_PROVIDED. > > > > > > > > Signed-off-by: Richard Purdie > > > > > > This breaks do_install in gpsd: > > > > > > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork > > > -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 > > > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > > > -o gpsd > > > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > > > -pthread > > > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/gpsd-3.7 > > > > > > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > > > gpsd.o ntpshm.o shmexport.o dbusexport.o sd_socket.o -L. > > > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > > > > > > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/lib > > > -lrt -lcap -lbluetooth -lgpsd -lusb-1.0 -lbluetooth -lgps -lm -lcap > > > | Install file: "gpsd" as > > > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > > > | chrpath -d > > > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > > > | > > > `/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd' > > > probably isn't a 64-bit LSB-first ELF file. > > > | elf_open: Exec format error > > > | scons: *** > > > [/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd] > > > Error 1 > > > | scons: building terminated because of errors. > > > | ERROR: scons install execution failed. > > > | ERROR: Function failed: do_install (see > > > /var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/temp/log.do_install.8833 > > > for further information) > > > NOTE: recipe gpsd-3.7-r9: task do_install: Failed > > > > > > I guess I can add chrpath-replacement-native to DEPENDS, but do you have > > > any > > > idea why chrpath in Ubuntu 14.04.1 does not support arm binaries? > > > $ chrpath --version > > > chrpath version 0.13 > > > > Er, chrpath should only get used on native/nativesdk/crosssdk/cross > > binaries. Its not expected to work on target binaries and we should > > never be running this there. > > > > Is this error coming from something we're putting in do_install or is it > > from gpsd's makefile? > > > > I think this might be a problem in the Makefile and not from OE itself. > > It's used from gpsd's SConstruct. > > I can remove it there, but that results in > WARNING: QA Issue: libgps: > > /work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/packages-split/libgps/usr/lib/libgps.so.20.0 > contains probably-redundant RPATH /usr/lib > or > WARNING: QA Issue: package libgps contains bad RPATH > > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/image/usr/lib > in file > > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/packages-split/libgps/usr/lib/libgps.so.20.0 Its clearly a gpsd build issue rather than anything in OE-Core. The former is a mild performance issue, the latter a potential security hole. Ideally, just stop gpsd putting any rpaths in... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gypsy: removed gypsy from meta/recipes-connectivity
removed also entry from
meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
Signed-off-by: Andrei Dinu
---
meta/recipes-connectivity/gypsy/files/fixups.patch | 21 -
meta/recipes-connectivity/gypsy/gypsy.inc | 15
meta/recipes-connectivity/gypsy/gypsy_0.9.bb | 24
meta/recipes-connectivity/gypsy/gypsy_git.bb | 18 ---
.../packagegroups/packagegroup-sdk-gmae.inc|1 -
5 files changed, 79 deletions(-)
delete mode 100644 meta/recipes-connectivity/gypsy/files/fixups.patch
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy.inc
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy_0.9.bb
delete mode 100644 meta/recipes-connectivity/gypsy/gypsy_git.bb
diff --git a/meta/recipes-connectivity/gypsy/files/fixups.patch
b/meta/recipes-connectivity/gypsy/files/fixups.patch
deleted file mode 100644
index de4d92e..000
--- a/meta/recipes-connectivity/gypsy/files/fixups.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
- docs/reference/Makefile.am |2 ++
- 1 file changed, 2 insertions(+)
-
gypsy.orig/docs/reference/Makefile.am
-+++ gypsy/docs/reference/Makefile.am
-@@ -81,10 +81,12 @@ expand_content_files=
- # e.g. GTKDOC_LIBS=$(top_builddir)/gtk/$(gtktargetlib)
-
- INCLUDES=-I$(top_srcdir) $(GYPSY_CFLAGS)
- GTKDOC_LIBS=$(top_builddir)/gypsy/libgypsy.la $(GYPSY_LIBS)
-
-+EXTRA_DIST =
-+CLEANFILES =
- # This includes the standard gtk-doc make rules, copied by gtkdocize.
- include $(top_srcdir)/gtk-doc.make
-
- # Other files to distribute
- # e.g. EXTRA_DIST += version.xml.in
diff --git a/meta/recipes-connectivity/gypsy/gypsy.inc
b/meta/recipes-connectivity/gypsy/gypsy.inc
deleted file mode 100644
index 0c1735e..000
--- a/meta/recipes-connectivity/gypsy/gypsy.inc
+++ /dev/null
@@ -1,15 +0,0 @@
-SUMMARY = "GPS Multiplexing Daemon"
-DESCRIPTION = "Gypsy is a GPS multiplexing daemon which allows \
-multiple clients to access GPS data from multiple GPS sources \
-concurrently. Gypsy also hides the details of parsing NMEA from the \
-client applications, passing the data as simple values for the clients \
-to use."
-LICENSE = "GPLv2.0 & LGPLv2.1"
-SECTION = "x11"
-DEPENDS = "glib-2.0 dbus bluez4 dbus-glib"
-
-inherit autotools pkgconfig gtk-doc
-
-EXTRA_OECONF += "--with-distro=debian"
-
-FILES_${PN} += "/usr/share/dbus-1/services/"
diff --git a/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
b/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
deleted file mode 100644
index 51207c9..000
--- a/meta/recipes-connectivity/gypsy/gypsy_0.9.bb
+++ /dev/null
@@ -1,24 +0,0 @@
-SUMMARY = "GPS Multiplexing Daemon"
-DESCRIPTION = "Gypsy is a GPS multiplexing daemon which allows \
-multiple clients to access GPS data from multiple GPS sources \
-concurrently. Gypsy also hides the details of parsing NMEA from the \
-client applications, passing the data as simple values for the clients \
-to use."
-LICENSE = "GPLv2+ & LGPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
-file://COPYING.lib;md5=7fbc338309ac38fefcd64b04bb903e34 \
-
file://src/main.c;beginline=1;endline=25;md5=3fe64e27e61b289b77383a54a982cbdd \
-
file://gypsy/gypsy-time.h;beginline=1;endline=24;md5=06432ea19a7b6607428d04d9dadc37fd"
-
-SECTION = "x11"
-DEPENDS = "glib-2.0 dbus bluez4 dbus-glib libxslt"
-
-SRC_URI = "http://gypsy.freedesktop.org/releases/gypsy-${PV}.tar.gz";
-PR = "r1"
-
-inherit autotools pkgconfig
-
-FILES_${PN} += "/usr/share/dbus-1/system-services/"
-
-SRC_URI[md5sum] = "e2d186df9c2cc3b70a027043e22acf1a"
-SRC_URI[sha256sum] =
"14e1cbe17351f408538e033ca370b4bf51ccf9c88744e236ddfb271904f154d6"
diff --git a/meta/recipes-connectivity/gypsy/gypsy_git.bb
b/meta/recipes-connectivity/gypsy/gypsy_git.bb
deleted file mode 100644
index 867582d..000
--- a/meta/recipes-connectivity/gypsy/gypsy_git.bb
+++ /dev/null
@@ -1,18 +0,0 @@
-require gypsy.inc
-
-DEFAULT_PREFERENCE = "-1"
-
-SRCREV = "3652e1f37e82b8e63983e30fda3482cd099a8cf5"
-PV = "0.8+git${SRCPV}"
-PR = "r2"
-
-S = "${WORKDIR}/git"
-
-LICENSE = "GPLv2+ & LGPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
-file://COPYING.lib;md5=7fbc338309ac38fefcd64b04bb903e34 \
-
file://src/main.c;beginline=1;endline=25;md5=3fe64e27e61b289b77383a54a982cbdd \
-
file://gypsy/gypsy-time.h;beginline=1;endline=24;md5=06432ea19a7b6607428d04d9dadc37fd"
-
-SRC_URI = "git://anongit.freedesktop.org/gypsy;protocol=git \
- file://fixups.patch"
diff --git a/meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
b/meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
index 2289572..a6403fc 100644
--- a/meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
+++ b/meta/recipes-gnome/packagegroups/packagegroup-sdk-gmae.inc
@@ -17,7 +17,6 @@ SDK-GMAE = "
Re: [OE-core] [oe-commits] Richard Purdie : bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
On Thu, Oct 04, 2012 at 10:28:35AM +0100, Richard Purdie wrote: > On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote: > > On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote: > > > Module: openembedded-core.git > > > Branch: master > > > Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a > > > URL: > > > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a > > > > > > Author: Richard Purdie > > > Date: Tue Oct 2 14:12:21 2012 +0100 > > > > > > bitbake.conf: Add chrpath-native to ASSUME_PROVIDED > > > > > > We assume chrpath is provided natively so it should be listed in > > > ASSUME_PROVIDED. > > > > > > Signed-off-by: Richard Purdie > > > > This breaks do_install in gpsd: > > > > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork > > -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 > > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > > -o gpsd > > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > > -pthread > > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/gpsd-3.7 > > > > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > > gpsd.o ntpshm.o shmexport.o dbusexport.o sd_socket.o -L. > > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > > > > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/lib > > -lrt -lcap -lbluetooth -lgpsd -lusb-1.0 -lbluetooth -lgps -lm -lcap > > | Install file: "gpsd" as > > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > > | chrpath -d > > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > > | > > `/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd' > > probably isn't a 64-bit LSB-first ELF file. > > | elf_open: Exec format error > > | scons: *** > > [/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd] > > Error 1 > > | scons: building terminated because of errors. > > | ERROR: scons install execution failed. > > | ERROR: Function failed: do_install (see > > /var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/temp/log.do_install.8833 > > for further information) > > NOTE: recipe gpsd-3.7-r9: task do_install: Failed > > > > I guess I can add chrpath-replacement-native to DEPENDS, but do you have > > any > > idea why chrpath in Ubuntu 14.04.1 does not support arm binaries? > > $ chrpath --version > > chrpath version 0.13 > > Er, chrpath should only get used on native/nativesdk/crosssdk/cross > binaries. Its not expected to work on target binaries and we should > never be running this there. > > Is this error coming from something we're putting in do_install or is it > from gpsd's makefile? > > I think this might be a problem in the Makefile and not from OE itself. It's used from gpsd's SConstruct. I can remove it there, but that results in WARNING: QA Issue: libgps: /work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/packages-split/libgps/usr/lib/libgps.so.20.0 contains probably-redundant RPATH /usr/lib or WARNING: QA Issue: package libgps contains bad RPATH /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/image/usr/lib in file /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gpsd/gpsd-3.5-r0/packages-split/libgps/usr/lib/libgps.so.20.0 Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Purdie : bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
On Thu, 2012-10-04 at 11:12 +0200, Martin Jansa wrote: > On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote: > > Module: openembedded-core.git > > Branch: master > > Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a > > URL: > > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a > > > > Author: Richard Purdie > > Date: Tue Oct 2 14:12:21 2012 +0100 > > > > bitbake.conf: Add chrpath-native to ASSUME_PROVIDED > > > > We assume chrpath is provided natively so it should be listed in > > ASSUME_PROVIDED. > > > > Signed-off-by: Richard Purdie > > This breaks do_install in gpsd: > > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork > -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > -o gpsd > --sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900 > -pthread > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/gpsd-3.7 > > -Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > gpsd.o ntpshm.o shmexport.o dbusexport.o sd_socket.o -L. > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib > > -L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/lib > -lrt -lcap -lbluetooth -lgpsd -lusb-1.0 -lbluetooth -lgps -lm -lcap > | Install file: "gpsd" as > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > | chrpath -d > "/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd" > | > `/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd' > probably isn't a 64-bit LSB-first ELF file. > | elf_open: Exec format error > | scons: *** > [/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd] > Error 1 > | scons: building terminated because of errors. > | ERROR: scons install execution failed. > | ERROR: Function failed: do_install (see > /var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/temp/log.do_install.8833 > for further information) > NOTE: recipe gpsd-3.7-r9: task do_install: Failed > > I guess I can add chrpath-replacement-native to DEPENDS, but do you have any > idea why chrpath in Ubuntu 14.04.1 does not support arm binaries? > $ chrpath --version > chrpath version 0.13 Er, chrpath should only get used on native/nativesdk/crosssdk/cross binaries. Its not expected to work on target binaries and we should never be running this there. Is this error coming from something we're putting in do_install or is it from gpsd's makefile? I think this might be a problem in the Makefile and not from OE itself. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtool: Add missing DEPENDS on libtool-cross
On Tue, 2012-10-02 at 16:30 -0500, Chase Maupin wrote: > * When building with 24 bitbake threads on my system I observed > errors like the following: > | configure.ac:199: error: LT_LANG: unsupported language: "Go" > | > /work/armv7a-vfp-neon-oe-linux-gnueabi/libtool-2.4.2-r3.0/libtool-2.4.2/aclocal-copy/libtool.m4:768: > LT_LANG is expanded from... > | configure.ac:199: the top level > | autom4te: m4 failed with exit status: 1 > * This could be found by doing a clean build. If a build had > already been performed then often just cleaning the libtool > package and rebuilding it would resolve the issue. > * Adding a DEPENDS on libtool-cross resolves this issue with a > clean build. > * Bump the PR So how do I reproduce this bug? In theory I'd just run "bitbake libtool" in a clean build directory? I've tried that with master and it all works? :/ Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Richard Purdie : bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
On Tue, Oct 02, 2012 at 04:18:50PM +, g...@git.openembedded.org wrote:
> Module: openembedded-core.git
> Branch: master
> Commit: 97a3ea712003e8d48dc68c282e656591f39d2d1a
> URL:
> http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=97a3ea712003e8d48dc68c282e656591f39d2d1a
>
> Author: Richard Purdie
> Date: Tue Oct 2 14:12:21 2012 +0100
>
> bitbake.conf: Add chrpath-native to ASSUME_PROVIDED
>
> We assume chrpath is provided natively so it should be listed in
> ASSUME_PROVIDED.
>
> Signed-off-by: Richard Purdie
This breaks do_install in gpsd:
| arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=softfp
-mfpu=neon -mtune=cortex-a8
--sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900
-o gpsd
--sysroot=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900
-pthread
-Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/gpsd-3.7
-Wl,-rpath=/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib
gpsd.o ntpshm.o shmexport.o dbusexport.o sd_socket.o -L.
-L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/lib
-L/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/sysroots/nokia900/lib
-lrt -lcap -lbluetooth -lgpsd -lusb-1.0 -lbluetooth -lgps -lm -lcap
| Install file: "gpsd" as
"/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd"
| chrpath -d
"/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd"
|
`/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd'
probably isn't a 64-bit LSB-first ELF file.
| elf_open: Exec format error
| scons: ***
[/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/image/usr/sbin/gpsd]
Error 1
| scons: building terminated because of errors.
| ERROR: scons install execution failed.
| ERROR: Function failed: do_install (see
/var/lib/jenkins/jobs/shr-core/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gpsd-3.7-r9/temp/log.do_install.8833
for further information)
NOTE: recipe gpsd-3.7-r9: task do_install: Failed
I guess I can add chrpath-replacement-native to DEPENDS, but do you have any
idea why chrpath in Ubuntu 14.04.1 does not support arm binaries?
$ chrpath --version
chrpath version 0.13
Cheers,
>
> ---
>
> meta/conf/bitbake.conf |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index e168ef1..c049b29 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -161,6 +161,7 @@ DATETIME = "${DATE}${TIME}"
> # its own in staging
> ASSUME_PROVIDED = "\
> bzip2-native \
> +chrpath-native \
> git-native \
> grep-native \
> diffstat-native \
> @@ -170,6 +171,7 @@ ASSUME_PROVIDED = "\
> tar-native \
> virtual/libintl-native \
> "
> +# gzip-native should be listed above?
>
> ##
> # Package default variables.
>
>
> ___
> Openembedded-commits mailing list
> openembedded-comm...@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
