[OE-core] [PATCH] update-alternatives: Don't process duplicated entries

[Jeremy Puhlman]

If ALTERNATIVE_ lists the same entry more then once, the
update-alternatives identical install and remove actions are added for
each repeated entry. This is exhibited when you add meta-selinux, and
examine the busybox package, which installs every link twice because it
alters the links to point to the shell replacements so selinux will work
with them. This can generate warnings on do_rootfs about similarly
prioritized alternatives. Given that at this point in the processing
the addtions should always be identical there shouldn't be any good
reason to add them twice.

Signed-off-by: Jeremy Puhlman 
---
 meta/classes/update-alternatives.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/update-alternatives.bbclass 
b/meta/classes/update-alternatives.bbclass
index aa01058..2c01c8b 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -207,7 +207,11 @@ python populate_packages_updatealternatives () {
 # Create post install/removal scripts
 alt_setup_links = ""
 alt_remove_links = ""
+already_processed = set()
 for alt_name in (d.getVar('ALTERNATIVE_%s' % pkg) or "").split():
+if alt_name in already_processed:
+   continue
+already_processed.add(alt_name)
 alt_link = d.getVarFlag('ALTERNATIVE_LINK_NAME', alt_name)
 alt_target   = d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg, 
alt_name) or d.getVarFlag('ALTERNATIVE_TARGET', alt_name)
 alt_target   = alt_target or d.getVar('ALTERNATIVE_TARGET_%s' % 
pkg) or d.getVar('ALTERNATIVE_TARGET') or alt_link
-- 
2.6.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Khem Raj]

On Fri, Jun 15, 2018 at 3:48 PM Andre McCurdy  wrote:

> On Fri, Jun 15, 2018 at 3:36 PM, Khem Raj  wrote:
> > On Fri, Jun 15, 2018 at 3:14 PM Mark Hatle 
> wrote:
> >>
> >> On 6/15/18 3:16 PM, Andre McCurdy wrote:
> >> > From: André Draszik 
> >> >
> >> > Some projects are starting to use it.
> >> >   https://spdx.org/licenses//BSD-1-Clause.html
> >> >
> >> > Signed-off-by: André Draszik 
> >> > Signed-off-by: Ross Burton 
> >> > (cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
> >> > Signed-off-by: Andre McCurdy 
> >> > ---
> >> >  meta/files/common-licenses/BSD-1-Clause | 9 +
> >> >  1 file changed, 9 insertions(+)
> >> >  create mode 100644 meta/files/common-licenses/BSD-1-Clause
> >> >
> >> > diff --git a/meta/files/common-licenses/BSD-1-Clause
> b/meta/files/common-licenses/BSD-1-Clause
> >> > new file mode 100644
> >> > index 000..ded8897
> >> > --- /dev/null
> >> > +++ b/meta/files/common-licenses/BSD-1-Clause
> >> > @@ -0,0 +1,9 @@
> >> > +
> >> > +Copyright (c) , 
> >> > +All rights reserved.
> >> > +
> >> > +Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are met:
> >> > +
> >> > +Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
> >> > +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS"
> AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> >>
> >> Hate to nitpick, but isn't BSDi defunct?  I don't think it makes sense
> to list
> >> BSDI, since as far as I know they never had a '1-Clause' license.
> >>
> >> Maybe a  would be more appropriate.
> >>
> >
> > I think we should sync the files we carry with SPDX e.g.
> > https://github.com/spdx/license-list-data/tree/master/text
>
> It doesn't look like that will fix the inconsistencies... those
> versions are inconsistent too:


We should report that to spdx folks since they
Work on licenses and might be interested in addressing this

>
>
> https://github.com/spdx/license-list-data/blob/master/text/BSD-1-Clause.txt
> : THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS"
>
> https://github.com/spdx/license-list-data/blob/master/text/BSD-2-Clause.txt
> : THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
>
> etc...
>
> >
> >> --Mark
> >>
> >> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE ARE
> >> DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE
> FOR ANY
> >> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES
> >> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> >> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON
> >> ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> >> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS
> >> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >> > +
> >> >
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] populate_sdk_ext.bbclass: fix corebase identification

[Damien Riegel]

When generating the extended SDK, there is a copy step where this class
goes through the layers and other stuff that have been copied to
generate the SDK. The corebase; ie. the folder that contains the core
layer 'meta' is treated in a special way. Unfortunately in our tree, we
have:

  sources/meta/meta
   | `- core layer
   `--- corebase

In populate_sdk_ext's copy_buildsystem, the heuristic to determine which
element of the list returned by copy_bitbake_and_layers is corebase is
fooled by such layout.

In copy_bitbake_and_layers, corebase is already handled specifically and
reliably, so we should let that function tell us which folder is
corebase instead of trying to determine it.

To do so, change the return type of copy_bitbake_and_layers to a tuple
that contains (corebase, copied_layers). It also simplifies the code on
the caller side.

Signed-off-by: Damien Riegel 
---
Changes in v3:
 - rebased on master to apply cleanly

Changes in v2:
 - move the logic in copy_bitbake_and_layers

 meta/classes/populate_sdk_ext.bbclass | 12 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 +---
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index e1bba49eaf..f0c8709c5b 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -200,15 +200,9 @@ python copy_buildsystem () {
 workspace_name = 'orig-workspace'
 else:
 workspace_name = None
-layers_copied = buildsystem.copy_bitbake_and_layers(baseoutpath + 
'/layers', workspace_name)
-
-sdkbblayers = []
-corebase = os.path.basename(d.getVar('COREBASE'))
-for layer in layers_copied:
-if corebase == os.path.basename(layer):
-conf_bbpath = os.path.join('layers', layer, 'bitbake')
-else:
-sdkbblayers.append(layer)
+
+corebase, sdkbblayers = buildsystem.copy_bitbake_and_layers(baseoutpath + 
'/layers', workspace_name)
+conf_bbpath = os.path.join('layers', corebase, 'bitbake')
 
 for path in os.listdir(baseoutpath + '/layers'):
 relpath = os.path.join('layers', path, oe_init_env_script)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 4b94806c73..4abec4666f 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -26,6 +26,7 @@ class BuildSystem(object):
 
 def copy_bitbake_and_layers(self, destdir, workspace_name=None):
 # Copy in all metadata layers + bitbake (as repositories)
+copied_corebase = None
 layers_copied = []
 bb.utils.mkdirhier(destdir)
 layers = list(self.layerdirs)
@@ -84,17 +85,18 @@ class BuildSystem(object):
 
 layer_relative = os.path.relpath(layerdestpath,
  destdir)
-layers_copied.append(layer_relative)
-
 # Treat corebase as special since it typically will contain
 # build directories or other custom items.
 if corebase == layer:
+copied_corebase = layer_relative
 bb.utils.mkdirhier(layerdestpath)
 for f in corebase_files:
 f_basename = os.path.basename(f)
 destname = os.path.join(layerdestpath, f_basename)
 _smart_copy(f, destname)
 else:
+layers_copied.append(layer_relative)
+
 if os.path.exists(os.path.join(layerdestpath, 
'conf/layer.conf')):
 bb.note("Skipping layer %s, already handled" % layer)
 else:
@@ -140,7 +142,7 @@ class BuildSystem(object):
 layers_copied.remove(layer)
 break
 
-return layers_copied
+return copied_corebase, layers_copied
 
 def generate_locked_sigs(sigfile, d):
 bb.utils.mkdirhier(os.path.dirname(sigfile))
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Andre McCurdy]

On Fri, Jun 15, 2018 at 3:36 PM, Khem Raj  wrote:
> On Fri, Jun 15, 2018 at 3:14 PM Mark Hatle  wrote:
>>
>> On 6/15/18 3:16 PM, Andre McCurdy wrote:
>> > From: André Draszik 
>> >
>> > Some projects are starting to use it.
>> >   https://spdx.org/licenses//BSD-1-Clause.html
>> >
>> > Signed-off-by: André Draszik 
>> > Signed-off-by: Ross Burton 
>> > (cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
>> > Signed-off-by: Andre McCurdy 
>> > ---
>> >  meta/files/common-licenses/BSD-1-Clause | 9 +
>> >  1 file changed, 9 insertions(+)
>> >  create mode 100644 meta/files/common-licenses/BSD-1-Clause
>> >
>> > diff --git a/meta/files/common-licenses/BSD-1-Clause 
>> > b/meta/files/common-licenses/BSD-1-Clause
>> > new file mode 100644
>> > index 000..ded8897
>> > --- /dev/null
>> > +++ b/meta/files/common-licenses/BSD-1-Clause
>> > @@ -0,0 +1,9 @@
>> > +
>> > +Copyright (c) , 
>> > +All rights reserved.
>> > +
>> > +Redistribution and use in source and binary forms, with or without 
>> > modification, are permitted provided that the following conditions are met:
>> > +
>> > +Redistributions of source code must retain the above copyright notice, 
>> > this list of conditions and the following disclaimer.
>> > +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND 
>> > ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>>
>> Hate to nitpick, but isn't BSDi defunct?  I don't think it makes sense to 
>> list
>> BSDI, since as far as I know they never had a '1-Clause' license.
>>
>> Maybe a  would be more appropriate.
>>
>
> I think we should sync the files we carry with SPDX e.g.
> https://github.com/spdx/license-list-data/tree/master/text

It doesn't look like that will fix the inconsistencies... those
versions are inconsistent too:

https://github.com/spdx/license-list-data/blob/master/text/BSD-1-Clause.txt
: THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS"

https://github.com/spdx/license-list-data/blob/master/text/BSD-2-Clause.txt
: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS"

etc...

>
>> --Mark
>>
>> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
>> ARE
>> DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR 
>> ANY
>> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND 
>> ON
>> ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> > +
>> >
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Khem Raj]

On Fri, Jun 15, 2018 at 3:14 PM Mark Hatle  wrote:
>
> On 6/15/18 3:16 PM, Andre McCurdy wrote:
> > From: André Draszik 
> >
> > Some projects are starting to use it.
> >   https://spdx.org/licenses//BSD-1-Clause.html
> >
> > Signed-off-by: André Draszik 
> > Signed-off-by: Ross Burton 
> > (cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
> > Signed-off-by: Andre McCurdy 
> > ---
> >  meta/files/common-licenses/BSD-1-Clause | 9 +
> >  1 file changed, 9 insertions(+)
> >  create mode 100644 meta/files/common-licenses/BSD-1-Clause
> >
> > diff --git a/meta/files/common-licenses/BSD-1-Clause 
> > b/meta/files/common-licenses/BSD-1-Clause
> > new file mode 100644
> > index 000..ded8897
> > --- /dev/null
> > +++ b/meta/files/common-licenses/BSD-1-Clause
> > @@ -0,0 +1,9 @@
> > +
> > +Copyright (c) , 
> > +All rights reserved.
> > +
> > +Redistribution and use in source and binary forms, with or without 
> > modification, are permitted provided that the following conditions are met:
> > +
> > +Redistributions of source code must retain the above copyright notice, 
> > this list of conditions and the following disclaimer.
> > +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND 
> > ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>
> Hate to nitpick, but isn't BSDi defunct?  I don't think it makes sense to list
> BSDI, since as far as I know they never had a '1-Clause' license.
>
> Maybe a  would be more appropriate.
>

I think we should sync the files we carry with SPDX e.g.
https://github.com/spdx/license-list-data/tree/master/text

> --Mark
>
> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR ANY
> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > +
> >
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Andre McCurdy]

On Fri, Jun 15, 2018 at 3:13 PM, Mark Hatle  wrote:
> On 6/15/18 3:16 PM, Andre McCurdy wrote:
>> From: André Draszik 
>>
>> Some projects are starting to use it.
>>   https://spdx.org/licenses//BSD-1-Clause.html
>>
>> Signed-off-by: André Draszik 
>> Signed-off-by: Ross Burton 
>> (cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
>> Signed-off-by: Andre McCurdy 
>> ---
>>  meta/files/common-licenses/BSD-1-Clause | 9 +
>>  1 file changed, 9 insertions(+)
>>  create mode 100644 meta/files/common-licenses/BSD-1-Clause
>>
>> diff --git a/meta/files/common-licenses/BSD-1-Clause 
>> b/meta/files/common-licenses/BSD-1-Clause
>> new file mode 100644
>> index 000..ded8897
>> --- /dev/null
>> +++ b/meta/files/common-licenses/BSD-1-Clause
>> @@ -0,0 +1,9 @@
>> +
>> +Copyright (c) , 
>> +All rights reserved.
>> +
>> +Redistribution and use in source and binary forms, with or without 
>> modification, are permitted provided that the following conditions are met:
>> +
>> +Redistributions of source code must retain the above copyright notice, this 
>> list of conditions and the following disclaimer.
>> +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND ANY 
>> EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>
> Hate to nitpick, but isn't BSDi defunct?  I don't think it makes sense to list
> BSDI, since as far as I know they never had a '1-Clause' license.

You're right.

There doesn't seem to be much consistency in the various BSD licenses
in meta/files/common-licenses. We currently have:

  BSD : THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' ...

  BSD-0-Clause : THE SOFTWARE IS PROVIDED "AS IS" ...

  BSD-1-Clause : THIS SOFTWARE IS PROVIDED BY Berkeley Software
Design, Inc. "AS IS" ...

  BSD-2-Clause : THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS`` ...

  BSD-3-Clause : THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
AND CONTRIBUTORS "AS IS" ...

  BSD-4-Clause : THIS SOFTWARE IS PROVIDED BY  ``AS IS`` ...

Every one slightly different!

> Maybe a  would be more appropriate.
>
> --Mark
>
> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR ANY
> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
> ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> +
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Mark Hatle]

On 6/15/18 3:16 PM, Andre McCurdy wrote:
> From: André Draszik 
> 
> Some projects are starting to use it.
>   https://spdx.org/licenses//BSD-1-Clause.html
> 
> Signed-off-by: André Draszik 
> Signed-off-by: Ross Burton 
> (cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
> Signed-off-by: Andre McCurdy 
> ---
>  meta/files/common-licenses/BSD-1-Clause | 9 +
>  1 file changed, 9 insertions(+)
>  create mode 100644 meta/files/common-licenses/BSD-1-Clause
> 
> diff --git a/meta/files/common-licenses/BSD-1-Clause 
> b/meta/files/common-licenses/BSD-1-Clause
> new file mode 100644
> index 000..ded8897
> --- /dev/null
> +++ b/meta/files/common-licenses/BSD-1-Clause
> @@ -0,0 +1,9 @@
> +
> +Copyright (c) , 
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without 
> modification, are permitted provided that the following conditions are met:
> +
> +Redistributions of source code must retain the above copyright notice, this 
> list of conditions and the following disclaimer.
> +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND ANY 
> EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 

Hate to nitpick, but isn't BSDi defunct?  I don't think it makes sense to list
BSDI, since as far as I know they never had a '1-Clause' license.

Maybe a  would be more appropriate.

--Mark

IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bitbake.conf: drop FETCHCMD, GITDIR, etc fetcher over-rides

[Andre McCurdy]

On Fri, Jun 15, 2018 at 2:58 PM, Richard Purdie
 wrote:
> On Fri, 2018-06-15 at 11:43 -0700, Andre McCurdy wrote:
>> Following recent updates to the bitbake, the fetchers should now all
>> contain safe and correct defaults for the subdirectory within DL_DIR
>> to use and the base fetch command to run. It's no longer necessary
>> for bitbake.conf to specify these values.
>>
>> This is cleanup which was originally proposed in 2012:
>>
>>   http://lists.openembedded.org/pipermail/openembedded-core/2012-July
>> /064224.html
>>
>> Signed-off-by: Andre McCurdy 
>> ---
>>  meta/conf/bitbake.conf | 12 
>>  1 file changed, 12 deletions(-)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 3b2ef9f..8588684 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -349,12 +349,6 @@ CACHE = "${TMPDIR}/cache${@['', '/' +
>> str(d.getVar('MACHINE'))][bool(d.getVar('M
>>  # The persistent cache should be shared by all builds
>>  PERSISTENT_DIR = "${TOPDIR}/cache"
>>  LOG_DIR = "${TMPDIR}/log"
>> -CO_DIR = "${DL_DIR}"
>> -CVSDIR = "${CO_DIR}/cvs"
>> -SVNDIR = "${CO_DIR}/svn"
>> -GITDIR = "${CO_DIR}/git2"
>> -BZRDIR = "${CO_DIR}/bzr"
>> -HGDIR = "${CO_DIR}/hg"
>>
>>  STAMPS_DIR ?= "${TMPDIR}/stamps"
>>  STAMP =
>> "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
>> @@ -661,12 +655,6 @@ SRC_URI[vardepsexclude] += "\
>>  #  export DEBIAN_MIRROR = "http://ftp.de.debian.org/debian/pool;
>>  # into your local.conf
>>
>> -FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-
>> cert"
>> -FETCHCMD_cvs = "/usr/bin/env cvs"
>> -FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp --no-
>> check-certificate"
>> -FETCHCMD_bzr = "/usr/bin/env bzr"
>> -FETCHCMD_hg = "/usr/bin/env hg"
>> -
>>  SRCDATE = "${DATE}"
>>  SRCREV ??= "INVALID"
>>  AUTOREV = "${@bb.fetch2.get_autorev(d)}"
>
> To make this work, we need to force everyone to upgrade their bitbake
> beyond the point where these have been added to the fetcher.
>
> We could do that with the minimum bitbake version but I'm tempted to
> hold this for a but until we have another more pressing reason to bump
> the minimum bitbake version and then do this at the same time?

OK. I was assuming that anyone using master oe-core would be using
master bitbake too. Delaying the change going into oe-core is
certainly safer though.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bitbake.conf: drop FETCHCMD, GITDIR, etc fetcher over-rides

[Richard Purdie]

On Fri, 2018-06-15 at 11:43 -0700, Andre McCurdy wrote:
> Following recent updates to the bitbake, the fetchers should now all
> contain safe and correct defaults for the subdirectory within DL_DIR
> to use and the base fetch command to run. It's no longer necessary
> for bitbake.conf to specify these values.
> 
> This is cleanup which was originally proposed in 2012:
> 
>   http://lists.openembedded.org/pipermail/openembedded-core/2012-July
> /064224.html
> 
> Signed-off-by: Andre McCurdy 
> ---
>  meta/conf/bitbake.conf | 12 
>  1 file changed, 12 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 3b2ef9f..8588684 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -349,12 +349,6 @@ CACHE = "${TMPDIR}/cache${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('M
>  # The persistent cache should be shared by all builds
>  PERSISTENT_DIR = "${TOPDIR}/cache"
>  LOG_DIR = "${TMPDIR}/log"
> -CO_DIR = "${DL_DIR}"
> -CVSDIR = "${CO_DIR}/cvs"
> -SVNDIR = "${CO_DIR}/svn"
> -GITDIR = "${CO_DIR}/git2"
> -BZRDIR = "${CO_DIR}/bzr"
> -HGDIR = "${CO_DIR}/hg"
>  
>  STAMPS_DIR ?= "${TMPDIR}/stamps"
>  STAMP =
> "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
> @@ -661,12 +655,6 @@ SRC_URI[vardepsexclude] += "\
>  #  export DEBIAN_MIRROR = "http://ftp.de.debian.org/debian/pool;
>  # into your local.conf
>  
> -FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-
> cert"
> -FETCHCMD_cvs = "/usr/bin/env cvs"
> -FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp --no-
> check-certificate"
> -FETCHCMD_bzr = "/usr/bin/env bzr"
> -FETCHCMD_hg = "/usr/bin/env hg"
> -
>  SRCDATE = "${DATE}"
>  SRCREV ??= "INVALID"
>  AUTOREV = "${@bb.fetch2.get_autorev(d)}"

To make this work, we need to force everyone to upgrade their bitbake
beyond the point where these have been added to the fetcher.

We could do that with the minimum bitbake version but I'm tempted to
hold this for a but until we have another more pressing reason to bump
the minimum bitbake version and then do this at the same time?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [rocko][PATCH] common-licenses: Add BSD-1-Clause

[Andre McCurdy]

From: André Draszik 

Some projects are starting to use it.
  https://spdx.org/licenses//BSD-1-Clause.html

Signed-off-by: André Draszik 
Signed-off-by: Ross Burton 
(cherry picked from commit 77f692ecb39d880b2cb420850a31534860eb2cc5)
Signed-off-by: Andre McCurdy 
---
 meta/files/common-licenses/BSD-1-Clause | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 meta/files/common-licenses/BSD-1-Clause

diff --git a/meta/files/common-licenses/BSD-1-Clause 
b/meta/files/common-licenses/BSD-1-Clause
new file mode 100644
index 000..ded8897
--- /dev/null
+++ b/meta/files/common-licenses/BSD-1-Clause
@@ -0,0 +1,9 @@
+
+Copyright (c) , 
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:
+
+Redistributions of source code must retain the above copyright notice, this 
list of conditions and the following disclaimer.
+THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND ANY 
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR ANY 
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; 
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON 
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] kernel-fitimage: Allow DTB file relocation at boot time

[Mihai Serban]

Use UBOOT_DTB_LOADADDRESS variable to instruct U-Boot where to place the
selected DTB file when booting the system.
Without this settings U-Boot uses the relative offset where DTB resides
inside the loading address of the FIT image.

Signed-off-by: Mihai Serban 
---

Changes since v1 (thanks to Alex Kiernan):
- remove entry line and UBOOT_DTB_ENTRYADDRESS since it is not used for DTBs

 meta/classes/kernel-fitimage.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 50a91e199069..b8ade9c38c73 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -134,6 +134,11 @@ EOF
 fitimage_emit_section_dtb() {
 
dtb_csum="sha1"
+   dtb_loadline=""
+
+   if [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
+   dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
+   fi
 
cat << EOF >> ${1}
 fdt@${2} {
@@ -142,6 +147,7 @@ fitimage_emit_section_dtb() {
 type = "flat_dt";
 arch = "${UBOOT_ARCH}";
 compression = "none";
+${dtb_loadline}
 hash@1 {
 algo = "${dtb_csum}";
 };
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel-fitimage: Allow DTB file relocation at boot time

[Mihai Serban]

On Fri, Jun 15, 2018 at 8:58 PM Alex Kiernan  wrote:
>
> On Fri, Jun 15, 2018 at 5:19 PM Mihai Serban  wrote:
> >
> > Use UBOOT_DTB_LOADADDRESS and UBOOT_DTB_ENTRYPOINT variables to instruct
> > U-Boot where to place the selected DTB file when booting the system.
> > Without these settings U-Boot uses the relative offset where DTB resides
> > inside the loading address of the FIT image.
> >
> > Signed-off-by: Mihai Serban 
>
> I've a similar patch I've been sitting on for a while, which also
> deals with the case where you want DTB overlays, but I don't have the
> entry line - what's the use for that in a DTB inside a FIT image?

Thanks for pointing this out. Entry is not used for DTB, I'll send v2.

>
> I'll get what I've got posted up.
>
> > ---
> >  meta/classes/kernel-fitimage.bbclass | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/meta/classes/kernel-fitimage.bbclass 
> > b/meta/classes/kernel-fitimage.bbclass
> > index 50a91e199069..981d11f19f8d 100644
> > --- a/meta/classes/kernel-fitimage.bbclass
> > +++ b/meta/classes/kernel-fitimage.bbclass
> > @@ -134,6 +134,15 @@ EOF
> >  fitimage_emit_section_dtb() {
> >
> > dtb_csum="sha1"
> > +   dtb_loadline=""
> > +   dtb_entryline=""
> > +
> > +   if [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
> > +   dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
> > +   fi
> > +   if [ -n "${UBOOT_DTB_ENTRYPOINT}" ]; then
> > +   dtb_entryline="entry = <${UBOOT_DTB_ENTRYPOINT}>;"
> > +   fi
> >
> > cat << EOF >> ${1}
> >  fdt@${2} {
> > @@ -142,6 +151,8 @@ fitimage_emit_section_dtb() {
> >  type = "flat_dt";
> >  arch = "${UBOOT_ARCH}";
> >  compression = "none";
> > +${dtb_loadline}
> > +${dtb_entryline}
> >  hash@1 {
> >  algo = "${dtb_csum}";
> >  };
> > --
> > 2.17.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Alex Kiernan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] sqlite3: consistent set of features for nativesdk

[S. Lockwood-Childs]

Enable use of pread() and enable column metadata API for all builds.
This brings nativesdk in line with target and native builds.

Signed-off-by: S. Lockwood-Childs 
---
 meta/recipes-support/sqlite/sqlite3.inc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/sqlite/sqlite3.inc 
b/meta/recipes-support/sqlite/sqlite3.inc
index 95ec89c..1834867d 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -36,12 +36,10 @@ EXTRA_OECONF = " \
 CFLAGS_append = " -fPIC"
 
 # pread() is in POSIX.1-2001 so any reasonable system must surely support it
-BUILD_CFLAGS += "-DUSE_PREAD"
-TARGET_CFLAGS += "-DUSE_PREAD"
+CFLAGS += "-DUSE_PREAD"
 
 # Provide column meta-data API
-BUILD_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
-TARGET_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
+CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
 
 PACKAGES = "lib${BPN} lib${BPN}-dev lib${BPN}-doc ${PN}-dbg 
lib${BPN}-staticdev ${PN}"
 
-- 
1.9.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] sqlite3: consistent set of features for nativesdk

[Khem Raj]

On Fri, Jun 15, 2018 at 12:58 AM S. Lockwood-Childs  wrote:
>
> Enable use of pread() and enable column metadata API for nativesdk builds.
> This brings nativesdk in line with target and native builds.
> ---
>  meta/recipes-support/sqlite/sqlite3.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-support/sqlite/sqlite3.inc 
> b/meta/recipes-support/sqlite/sqlite3.inc
> index 95ec89c..30847b9 100644
> --- a/meta/recipes-support/sqlite/sqlite3.inc
> +++ b/meta/recipes-support/sqlite/sqlite3.inc
> @@ -37,10 +37,12 @@ CFLAGS_append = " -fPIC"
>
>  # pread() is in POSIX.1-2001 so any reasonable system must surely support it
>  BUILD_CFLAGS += "-DUSE_PREAD"
> +BUILDSDK_CFLAGS += "-DUSE_PREAD"
>  TARGET_CFLAGS += "-DUSE_PREAD"
>

Perhaps, we can just add it to CPPFLAGS and remove all three lines above

>  # Provide column meta-data API
>  BUILD_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
> +BUILDSDK_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
>  TARGET_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
>

same as above

>  PACKAGES = "lib${BPN} lib${BPN}-dev lib${BPN}-doc ${PN}-dbg 
> lib${BPN}-staticdev ${PN}"
> --
> 1.9.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] rsync: merge rsync.inc into the rsync recipe

[Andre McCurdy]

There's only one user of rsync.inc (meta-gplv2 has its own copy), so
merge the .inc file into the rsync recipe.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-devtools/rsync/rsync.inc  | 20 
 meta/recipes-devtools/rsync/rsync_3.1.3.bb | 28 +++-
 2 files changed, 23 insertions(+), 25 deletions(-)
 delete mode 100644 meta/recipes-devtools/rsync/rsync.inc

diff --git a/meta/recipes-devtools/rsync/rsync.inc 
b/meta/recipes-devtools/rsync/rsync.inc
deleted file mode 100644
index 26c023a..000
--- a/meta/recipes-devtools/rsync/rsync.inc
+++ /dev/null
@@ -1,20 +0,0 @@
-SUMMARY = "File synchronization tool"
-HOMEPAGE = "http://rsync.samba.org/;
-BUGTRACKER = "http://rsync.samba.org/bugzilla.html;
-SECTION = "console/network"
-
-DEPENDS = "popt"
-
-SRC_URI = "https://download.samba.org/pub/${BPN}/src/${BP}.tar.gz \
-   file://rsyncd.conf"
-
-inherit autotools
-
-do_install_append() {
-   install -d ${D}${sysconfdir}
-   install -m 0644 ${WORKDIR}/rsyncd.conf ${D}${sysconfdir}
-}
-
-EXTRA_OEMAKE='STRIP=""'
-
-PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
diff --git a/meta/recipes-devtools/rsync/rsync_3.1.3.bb 
b/meta/recipes-devtools/rsync/rsync_3.1.3.bb
index 84a0258..29cb231 100644
--- a/meta/recipes-devtools/rsync/rsync_3.1.3.bb
+++ b/meta/recipes-devtools/rsync/rsync_3.1.3.bb
@@ -1,24 +1,37 @@
-require rsync.inc
+SUMMARY = "File synchronization tool"
+HOMEPAGE = "http://rsync.samba.org/;
+BUGTRACKER = "http://rsync.samba.org/bugzilla.html;
+SECTION = "console/network"
+# GPLv2+ (<< 3.0.0), GPLv3+ (>= 3.0.0)
+LICENSE = "GPLv3+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
-SRC_URI += "file://makefile-no-rebuild.patch"
+DEPENDS = "popt"
+
+SRC_URI = "https://download.samba.org/pub/${BPN}/src/${BP}.tar.gz \
+   file://rsyncd.conf \
+   file://makefile-no-rebuild.patch \
+"
 
 SRC_URI[md5sum] = "1581a588fde9d89f6bc6201e8129afaf"
 SRC_URI[sha256sum] = 
"55cc554efec5fdaad70de921cd5a5eeb6c29a95524c715f3bbf849235b0800c0"
 
-# GPLv2+ (<< 3.0.0), GPLv3+ (>= 3.0.0)
-LICENSE = "GPLv3+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+inherit autotools
 
 PACKAGECONFIG ??= "acl attr \
 ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
 "
+
 PACKAGECONFIG[acl] = "--enable-acl-support,--disable-acl-support,acl,"
 PACKAGECONFIG[attr] = "--enable-xattr-support,--disable-xattr-support,attr,"
+PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
 
 # By default, if crosscompiling, rsync disables a number of
 # capabilities, hardlinking symlinks and special files (i.e. devices)
 CACHED_CONFIGUREVARS += "rsync_cv_can_hardlink_special=yes 
rsync_cv_can_hardlink_symlink=yes"
 
+EXTRA_OEMAKE = 'STRIP=""'
+
 # rsync 3.0 uses configure.sh instead of configure, and
 # makefile checks the existence of configure.sh
 do_configure_prepend () {
@@ -29,4 +42,9 @@ do_configure_append () {
cp -f ${S}/configure ${S}/configure.sh
 }
 
+do_install_append() {
+   install -d ${D}${sysconfdir}
+   install -m 0644 ${WORKDIR}/rsyncd.conf ${D}${sysconfdir}
+}
+
 BBCLASSEXTEND = "native"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bitbake.conf: drop FETCHCMD, GITDIR, etc fetcher over-rides

[Andre McCurdy]

Following recent updates to the bitbake, the fetchers should now all
contain safe and correct defaults for the subdirectory within DL_DIR
to use and the base fetch command to run. It's no longer necessary
for bitbake.conf to specify these values.

This is cleanup which was originally proposed in 2012:

  
http://lists.openembedded.org/pipermail/openembedded-core/2012-July/064224.html

Signed-off-by: Andre McCurdy 
---
 meta/conf/bitbake.conf | 12 
 1 file changed, 12 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 3b2ef9f..8588684 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -349,12 +349,6 @@ CACHE = "${TMPDIR}/cache${@['', '/' + 
str(d.getVar('MACHINE'))][bool(d.getVar('M
 # The persistent cache should be shared by all builds
 PERSISTENT_DIR = "${TOPDIR}/cache"
 LOG_DIR = "${TMPDIR}/log"
-CO_DIR = "${DL_DIR}"
-CVSDIR = "${CO_DIR}/cvs"
-SVNDIR = "${CO_DIR}/svn"
-GITDIR = "${CO_DIR}/git2"
-BZRDIR = "${CO_DIR}/bzr"
-HGDIR = "${CO_DIR}/hg"
 
 STAMPS_DIR ?= "${TMPDIR}/stamps"
 STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
@@ -661,12 +655,6 @@ SRC_URI[vardepsexclude] += "\
 #  export DEBIAN_MIRROR = "http://ftp.de.debian.org/debian/pool;
 # into your local.conf
 
-FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-cert"
-FETCHCMD_cvs = "/usr/bin/env cvs"
-FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp 
--no-check-certificate"
-FETCHCMD_bzr = "/usr/bin/env bzr"
-FETCHCMD_hg = "/usr/bin/env hg"
-
 SRCDATE = "${DATE}"
 SRCREV ??= "INVALID"
 AUTOREV = "${@bb.fetch2.get_autorev(d)}"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] runqemu: Allow the user to specity DTB

[Ben Levinsky]

In some cirsumstances the user doesn't want to supply a kernel, rootFS
to QEMU, but only a DTB.

Allow users to specify dtb for supply via the QB_DTB option
to QEMU.

Signed-off-by: Ben Levinsky 
---
 scripts/runqemu | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index 0b6daf2..075b3b9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -604,7 +604,9 @@ class BaseConfig(object):
 if not os.path.exists(self.kernel):
 raise RunQemuError("KERNEL %s not found" % self.kernel)
 
+def check_dtb(self):
 dtb = self.get('QB_DTB')
+deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
 if dtb:
 cmd_match = "%s/%s" % (deploy_dir_image, dtb)
 cmd_startswith = "%s/%s*" % (deploy_dir_image, dtb)
@@ -674,6 +676,7 @@ class BaseConfig(object):
 self.check_rootfs()
 self.check_ovmf()
 self.check_kernel()
+self.check_dtb()
 self.check_biosdir()
 self.check_mem()
 self.check_tcpserial()
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel-fitimage: Allow DTB file relocation at boot time

[Alex Kiernan]

On Fri, Jun 15, 2018 at 5:19 PM Mihai Serban  wrote:
>
> Use UBOOT_DTB_LOADADDRESS and UBOOT_DTB_ENTRYPOINT variables to instruct
> U-Boot where to place the selected DTB file when booting the system.
> Without these settings U-Boot uses the relative offset where DTB resides
> inside the loading address of the FIT image.
>
> Signed-off-by: Mihai Serban 

I've a similar patch I've been sitting on for a while, which also
deals with the case where you want DTB overlays, but I don't have the
entry line - what's the use for that in a DTB inside a FIT image?

I'll get what I've got posted up.

> ---
>  meta/classes/kernel-fitimage.bbclass | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/meta/classes/kernel-fitimage.bbclass 
> b/meta/classes/kernel-fitimage.bbclass
> index 50a91e199069..981d11f19f8d 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -134,6 +134,15 @@ EOF
>  fitimage_emit_section_dtb() {
>
> dtb_csum="sha1"
> +   dtb_loadline=""
> +   dtb_entryline=""
> +
> +   if [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
> +   dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
> +   fi
> +   if [ -n "${UBOOT_DTB_ENTRYPOINT}" ]; then
> +   dtb_entryline="entry = <${UBOOT_DTB_ENTRYPOINT}>;"
> +   fi
>
> cat << EOF >> ${1}
>  fdt@${2} {
> @@ -142,6 +151,8 @@ fitimage_emit_section_dtb() {
>  type = "flat_dt";
>  arch = "${UBOOT_ARCH}";
>  compression = "none";
> +${dtb_loadline}
> +${dtb_entryline}
>  hash@1 {
>  algo = "${dtb_csum}";
>  };
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Alex Kiernan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] [meta] atk: Specify gettext-native dependency

[Alistair Francis]

On Mon, Jun 4, 2018 at 4:18 PM, Burton, Ross  wrote:
> That implies that INHIBIT_DEFAULT_DEPS is also evaluating to true,
> which it shouldn't be in ATK.
>
> I'd definitely be checking if that is the case, and if you can
> replicate the failure with e.g. qemuarm.

I can't replicate it with qemuarm and checking with bitbake -e I can't
see anywhere that the variable is set. Any ideas on what to try to
figure out how it is set?

Alistair

>
> Ross
>
> On 4 June 2018 at 19:46, Alistair Francis  wrote:
>> On Mon, Jun 4, 2018 at 10:20 AM, Alexander Kanavin
>>  wrote:
>>> On 06/04/2018 08:17 PM, Alistair Francis wrote:

 On Mon, Jun 4, 2018 at 3:06 AM, Burton, Ross 
 wrote:
>
> So why isn't the inherit gettext sufficient?


 I'm not sure. Here is the error I see when compiling for RISC-V before
 this patch:
>>>
>>>
>>> So is the error specific to risc-v? You should dig deeper in that direction
>>> then.
>>
>> Ok, it looks like the line: if d.getVar('INHIBIT_DEFAULT_DEPS') and
>> not oe.utils.inherits(d, 'cross-canadian'): is evaluating as true in
>> gettext.bbclass so we don't depend on gettext-native.
>>
>> Do I need to ensure cross-canadian is set for RISC-V builds then?
>>
>> Alistair
>>
>>>
>>> Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [v3][PATCH] bind: update to 9.12.1

[Burton, Ross]

On 28 May 2018 at 15:11, Armin Kuster  wrote:
> [v3]
> Made formating and spelling changes per Martin
>
> [v2]
> Remove python3 in default PACKACKECONFIG
> include https://patchwork.openembedded.org/patch/148257/
> Because of the newly added dependency on meta-python, the python(3)
> packageconfig is no longer "default-on".

All of this should be under the scissors so it doesnt go in the commit.

> Requires python-ply package in core

Comment says use meta-python.  If the python code here is useful, we
can add it to core.

> removed:
> dont-test-on-host.patch, no longer impliemented

"implemented"

>   --disable-devpoll --enable-epoll --with-gost=no \
> - --with-gssapi=no --with-ecdsa=yes \
> + --with-gssapi=no --with-ecdsa=yes --with-eddsa=no \

Should we be adding PACKAGECONFIGs for these?

> +#
> +# If python3 is enabled you will need to inlcude the meta-python
> +# layer to include the dependency package python-ply
> +#

Conflicts with the commit message.  Pick one.

> +PACKAGECONFIG[python3] = "--with-python=${PYTHON}, --without-python, 
> python3-native python3-ply-native, python3-core"

Just python3-core sounds unlikely as that's a subset of the standard library.

I tried to enable python3 and nothing was built.  Configure found the
python modules it was looking for, but nothing happened when it went
into python/.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Andre McCurdy]

On Fri, Jun 15, 2018 at 3:41 AM, Herve Jourdain  wrote:
> Hi,
>
> Actually, I meant "works" in the sense of "does compile" - as opposed to 
> armv8 where it does not compile, which is why we're having this discussion in 
> the first place.
> So I was merely suggesting to not modify previous oe behavior for the db 
> package for previous architectures, and just add the removal of 'swp' for 
> armv8, where it matters most.
>
> If we want to look at it in details, based on the "ARM Architecture Reference 
> Manual ARMv7-A and ARMv7-R edition":
> 1. SWP is the way to go before ARMv6.
> 2. SWP has been deprecated in ARMv6.
> 3. SWP has been deprecated AND made optional in ARMv7ve.
> 4. "The SWP and SWPB instructions rely on the properties of the system beyond 
> the processor to ensure that no stores from other observers can occur between 
> the load access and the store access, and this might not be implemented for 
> all regions of memory on some system implementations. In all cases, SWP and 
> SWPB do ensure that no stores from the processor that executed the SWP or 
> SWPB instruction can occur between the load access and the store access of 
> the SWP or SWPB."
>
> This latest part means that it may or may not work in SMP environments, it 
> depends on how the system is architecture around the cores - most likely how 
> the bus system is designed I believe. So it may actually be working fine if 
> the system/bus designer has taken that into account.
>
> This said, I believe that from point #3 above, it might make sense to disable 
> SWP for armv7ve as well, since being optional means that it might be compiled 
> correctly, but still fail at runtime, depending on the choices of the SoC 
> manufacturer.
> So my recommendation would be to add:
> MUTEX_armv7ve = ""
> MUTEX_armv8 = ""
>
> To disable 'swp' by default only for those 2 archs, while keeping things like 
> they are for previous architectures.

Thanks for your long and detailed explanation! Adding together the
time which has gone into this thread so far and the time which went
into a similar thread in 2016, it perfectly illustrates the
maintenance effort which goes into enabling this architecture specific
micro optimisation.

  https://patchwork.openembedded.org/patch/133590/

> Cheers,
> Herve
>
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: vendredi 15 juin 2018 09:39
> To: Herve Jourdain 
> Cc: Khem Raj ; Ovidiu Panait 
> ; Patches and discussions about the oe-core 
> layer 
> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>
> On Fri, Jun 15, 2018 at 12:10 AM, Herve Jourdain  
> wrote:
>> Hi,
>>
>> So the issue is whether we want to change the behaviour of previous 
>> architectures, or if we try to fix the issue only for the architectures that 
>> don't work.
>> Until now, the db recipe was enabling the 'swp' optimization, and that 
>> behavior could be disabled on .bbappend if needed.
>> While that works fine until armv7ve, it does not work for armv8, which has 
>> removed support for those instructions.
>
> I don't know if "works fine until armv7ve" is correct. Although the swp 
> instruction exists for armv7, according to the link I posted yesterday, it is 
> not guaranteed to work.
>
>   
> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
>
> Or do you have other evidence to suggest that swp is safe to use for armv7?
>
>> Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
>> can be safely used on previous architectures.
>> If we remove the use for all ARM architectures, that might create some 
>> regression/issues.
>> If we just remove the use of 'swp' only for armv8, we ensure it doesn't 
>> break anything that's running on previous ARM architectures.
>>
>> Cheers,
>> Herve
>>
>> -Original Message-
>> From: Andre McCurdy [mailto:armccu...@gmail.com]
>> Sent: vendredi 15 juin 2018 00:03
>> To: Khem Raj 
>> Cc: Herve Jourdain ; Ovidiu Panait
>> ; Patches and discussions about the
>> oe-core layer 
>> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex
>> code
>>
>> On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
>>> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
 On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
 > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy
 > 
 > wrote:
 >>
 >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
 >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
 >> >> Hi,
 >> >>
 >> >> I believe I solved that same problem by just adding, in the
 >> >> case of
 >> >> armv8
 >> >> (which I believe may be the new architecture you're referring to):
 >> >> MUTEX_armv8 = ""
 >> >> This way, it allows previous versions to work just like they
 >> >> did before, without having to disable ARM assembler mutex code
 >> >> for architectures that support it correctly - up to armv7ve I
 >> >> believe.

[OE-core] [PATCH] kernel-fitimage: Allow DTB file relocation at boot time

[Mihai Serban]

Use UBOOT_DTB_LOADADDRESS and UBOOT_DTB_ENTRYPOINT variables to instruct
U-Boot where to place the selected DTB file when booting the system.
Without these settings U-Boot uses the relative offset where DTB resides
inside the loading address of the FIT image.

Signed-off-by: Mihai Serban 
---
 meta/classes/kernel-fitimage.bbclass | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 50a91e199069..981d11f19f8d 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -134,6 +134,15 @@ EOF
 fitimage_emit_section_dtb() {
 
dtb_csum="sha1"
+   dtb_loadline=""
+   dtb_entryline=""
+
+   if [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
+   dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
+   fi
+   if [ -n "${UBOOT_DTB_ENTRYPOINT}" ]; then
+   dtb_entryline="entry = <${UBOOT_DTB_ENTRYPOINT}>;"
+   fi
 
cat << EOF >> ${1}
 fdt@${2} {
@@ -142,6 +151,8 @@ fitimage_emit_section_dtb() {
 type = "flat_dt";
 arch = "${UBOOT_ARCH}";
 compression = "none";
+${dtb_loadline}
+${dtb_entryline}
 hash@1 {
 algo = "${dtb_csum}";
 };
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/5] arch-armv8a.inc: add tune include for armv8

[ayaka]

On 06/15/2018 05:57 PM, Nicolas Dechesne wrote:

On Fri, Jun 15, 2018 at 5:22 AM, Randy Li  wrote:

There are some addtional instructions apart from bare armv8,
also there is armv8.1, armv8.2.

Most the processor would support crc, except X-gene 1.

Signed-off-by: Randy Li 
---
  meta/conf/machine/include/arm/arch-armv8.inc  |  1 -
  meta/conf/machine/include/arm/arch-armv8a.inc | 28 +++
  2 files changed, 28 insertions(+), 1 deletion(-)
  delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc

My previous comment still applies here. You can't just delete this
file. It's used by many BSP. and it's even used in oe-core itself:

layers/openembedded-core/meta/conf/machine/include/tune-thunderx.inc:require
conf/machine/include/arm/arch-armv8.inc
layers/openembedded-core/meta/conf/machine/qemuarm64.conf:require
conf/machine/include/arm/arch-armv8.inc

I am very sorry about, should I modify those files the same time?
Since some cortex-m processors also support armv8 instructions, it would 
be used to run Linux in the

future.
Also there would be armv81a, armv82a for the optimization of the 
armv8.1, armv8.2.

That is why I want to rename it.

Apart from that ,would you pleased with the contents below?



  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
b/meta/conf/machine/include/arm/arch-armv8.inc
deleted file mode 100644
index 5e832fae6d..00
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ /dev/null
@@ -1 +0,0 @@
-require conf/machine/include/arm/arch-arm64.inc
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
b/meta/conf/machine/include/arm/arch-armv8a.inc
new file mode 100644
index 00..323d0d7f0f
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -0,0 +1,28 @@
+DEFAULTTUNE ?= "armv8a-crc"
+
+TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' -march=armv8-a', 
'', d)}"
+TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and 
floating-point"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', d)}"
+TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check 
(CRC)"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
+TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', '', 
d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', 'armv8a:', '' 
,d)}"
+
+require conf/machine/include/arm/arch-arm64.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
+ARMPKGARCH_tune-armv8a?= "armv8a"
+ARMPKGARCH_tune-armv8a-crc?= "armv8a"
+ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
+ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
+TUNE_FEATURES_tune-armv8a  = "aarch64 armv8a simd"
+TUNE_FEATURES_tune-armv8a-crc  = "${TUNE_FEATURES_tune-armv8a} crc"
+TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
crypto"
+TUNE_FEATURES_tune-armv8a-crc-crypto   = "${TUNE_FEATURES_tune-armv8a-crc} 
crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= "${PACKAGE_EXTRA_ARCHS_tune-armv8a} 
crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a} 
crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
--
2.14.4

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] initramfs-framework: add nfsrootfs module

[Oleksii Konoplitskyi via Openembedded-core]

Hi Andre,


Could you, please, check if all the features that we discussed in 
https://patchwork.openembedded.org/patch/149212/ are implemented in this 
patch?



Best regards,

Oleksii


On 25.05.18 16:56, Oleksii Konoplitskyi wrote:

nfsrootfs module mounts rootfs via nfs parsing "nfsroot" and "ip" cmdline 
options.

Signed-off-by: Oleksii Konoplitskyi 
---
  .../initrdscripts/initramfs-framework/nfsrootfs| 48 ++
  .../initrdscripts/initramfs-framework_1.0.bb   |  7 
  2 files changed, 55 insertions(+)
  create mode 100644 
meta/recipes-core/initrdscripts/initramfs-framework/nfsrootfs

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/nfsrootfs 
b/meta/recipes-core/initrdscripts/initramfs-framework/nfsrootfs
new file mode 100644
index 000..e67ee4c
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/nfsrootfs
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+nfsrootfs_enabled() {
+   if [ ${bootparam_root} != "/dev/nfs" ] || [ -z ${bootparam_nfsroot} ]; 
then
+   return 1
+   fi
+   return 0
+}
+
+nfsrootfs_run() {
+   local nfs_opts
+   local location
+   local flags
+   local server_ip
+
+   nfs_opts=""
+   if [ "${bootparam_nfsroot#*,}" != "${bootparam_nfsroot}" ]; then
+   nfs_opts="-o ${bootparam_nfsroot#*,}"
+   fi
+
+   location="${bootparam_nfsroot%%,*}"
+   if [ "${location#*:}" = "${location}" ]; then
+   # server-ip not given. Get server ip from ip option
+   server_ip=""
+   if [ "${bootparam_ip#*:}" != "${bootparam_ip}" ]; then
+   server_ip=$(echo "$bootparam_ip" | cut -d: -f2)
+   fi
+
+   if [ -z "$server_ip" ]; then
+   fatal "Server IP is not set. Update ip or nfsroot 
options."
+   fi
+   location=${server_ip}:${location}
+   fi
+
+   flags="-o nolock"
+   if [ -n "$bootparam_ro" ] && ! echo "$bootparam_rootflags" | grep -w -q 
"ro"; then
+   if [  -n "$bootparam_rootflags" ]; then
+   bootparam_rootflags="$bootparam_rootflags,"
+   fi
+   bootparam_rootflags="${bootparam_rootflags}ro"
+   fi
+   if [ -n "$bootparam_rootflags" ]; then
+   flags="$flags -o $bootparam_rootflags"
+   fi
+
+   mount -t nfs ${flags} ${nfs_opts} ${location} ${ROOTFS_DIR}
+}
+
diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 75d965f..6337b99 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -9,6 +9,7 @@ inherit allarch
  
  SRC_URI = "file://init \

 file://exec \
+   file://nfsrootfs \
 file://rootfs \
 file://finish \
 file://mdev \
@@ -24,6 +25,7 @@ do_install() {
  
  # base

  install -m 0755 ${WORKDIR}/init ${D}/init
+install -m 0755 ${WORKDIR}/nfsrootfs ${D}/init.d/85-nfsrootfs
  install -m 0755 ${WORKDIR}/rootfs ${D}/init.d/90-rootfs
  install -m 0755 ${WORKDIR}/finish ${D}/init.d/99-finish
  
@@ -53,6 +55,7 @@ PACKAGES = "${PN}-base \

  initramfs-module-mdev \
  initramfs-module-udev \
  initramfs-module-e2fs \
+initramfs-module-nfsrootfs \
  initramfs-module-rootfs \
  initramfs-module-debug \
 "
@@ -83,6 +86,10 @@ SUMMARY_initramfs-module-e2fs = "initramfs support for 
ext4/ext3/ext2 filesystem
  RDEPENDS_initramfs-module-e2fs = "${PN}-base"
  FILES_initramfs-module-e2fs = "/init.d/10-e2fs"
  
+SUMMARY_initramfs-module-nfsrootfs = "initramfs support for locating and mounting the root partition via nfs"

+RDEPENDS_initramfs-module-nfsrootfs = "${PN}-base"
+FILES_initramfs-module-nfsrootfs = "/init.d/85-nfsrootfs"
+
  SUMMARY_initramfs-module-rootfs = "initramfs support for locating and mounting the 
root partition"
  RDEPENDS_initramfs-module-rootfs = "${PN}-base"
  FILES_initramfs-module-rootfs = "/init.d/90-rootfs"


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] alsa-tools: rewrite packaging

[Ross Burton]

alsa-tools is actually a collection of 20 separate tools, each with their own
configure scripts.  The dependencies are varied, old, and estoric (FLTK, GTK+ 
1, 2,
and 3, PyGTK 2, Qt3).

Instead of maintaining patches to try and pick a subset that builds, use
PACKAGECONFIG and some magic to build what the user requests.

By default we build all the tools which have no dependencies, and the tools
which need GTK+ 2 or GTK+ 3 if the relevant DISTRO_FEATURES are enabled.

Add a patch to fix the build of ld10k1 with musl.

The ncurses build dependency doesn't seem to be checked for, so remove that.

(From OE-Core rev: 83c9405df5748744ef673ac8757bb89d7050ad8d)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
 ...g-Wreserved-user-defined-literal-warnings.patch | 14 +++-
 .../alsa/alsa-tools/autotools.patch| 44 ---
 .../alsa/alsa-tools/gitcompile_hdajacksensetest| 13 ---
 .../alsa/alsa-tools/makefile_no_gtk.patch  | 29 ---
 meta/recipes-multimedia/alsa/alsa-tools/musl.patch | 47 +++
 meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb   | 92 +++---
 6 files changed, 119 insertions(+), 120 deletions(-)
 delete mode 100644 meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
 delete mode 100755 
meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
 create mode 100644 meta/recipes-multimedia/alsa/alsa-tools/musl.patch

diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
 
b/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
index 2290915eab8..c137bc8a284 100644
--- 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
+++ 
b/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
@@ -1,14 +1,18 @@
-From 2e48e4045e1e951433da0ca4b1e49798eedde14f Mon Sep 17 00:00:00 2001
+Upstream-Status: Backport
+Signed-off-by: Khem Raj 
+
+From a861bdabf02cd9bfb3ec7c0571c563c0fa14adfb Mon Sep 17 00:00:00 2001
 From: Khem Raj 
-Date: Tue, 24 Apr 2018 12:21:18 -0700
-Subject: [PATCH] Fix clang -Wreserved-user-defined-literal warnings
+Date: Tue, 24 Apr 2018 12:24:32 -0700
+Subject: [PATCH] us428control: Fix clang -Wreserved-user-defined-literal
+ warnings
 
 | us428control.cc:66:18: error: invalid suffix on literal; C++11 requires a 
space between literal and identifier [-Wreserved-user-defined-literal]
 | printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
 | ^
 
-Upstream-Status: Submitted [https://patchwork.kernel.org/patch/10360805/]
 Signed-off-by: Khem Raj 
+Signed-off-by: Takashi Iwai 
 ---
  us428control/us428control.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
@@ -26,3 +30,5 @@ index e839bf4..8cb3c42 100644
printf("mode is one of (us224, us428, mixxx)\n");
  }
  /*
+-- 
+1.7.11.7
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch 
b/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
deleted file mode 100644
index c85834a593c..000
--- a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From b9a65bf3ba5628cfe8cfd2d10ce2dcf11a606775 Mon Sep 17 00:00:00 2001
-From: Dongxiao Xu 
-Date: Thu, 14 Jul 2011 15:40:36 +0800
-Subject: [PATCH] alsa-tools: Fix recipe build error.
-
-Add parameters to autoreconf to support cross compile.
-Remove some sub-components which needs further recipe support.
-
-Signed-off-by: Dongxiao Xu 
-
-Upstream-Status: Inappropriate [configuration]
-

- Makefile  | 4 ++--
- ld10k1/gitcompile | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/Makefile b/Makefile
-index c32bf25..1119372 100644
 a/Makefile
-+++ b/Makefile
-@@ -1,8 +1,8 @@
- VERSION = 1.1.6
- TOP = .
--SUBDIRS = as10k1 envy24control hdsploader hdspconf hdspmixer \
-+SUBDIRS = as10k1 envy24control \
- mixartloader pcxhrloader rmedigicontrol sb16_csp seq sscape_ctl \
--us428control usx2yloader vxloader echomixer ld10k1 qlo10k1 \
-+us428control usx2yloader vxloader echomixer \
- hwmixvolume hdajackretask hda-verb hdajacksensetest
- 
- all:
-diff --git a/ld10k1/gitcompile b/ld10k1/gitcompile
-index 99429ac..20005d9 100755
 a/ld10k1/gitcompile
-+++ b/ld10k1/gitcompile
-@@ -1,6 +1,6 @@
- #!/bin/bash
- 
--autoreconf -fi || exit 1
-+autoreconf $ACLOCAL_FLAGS -fi || exit 1
- export CFLAGS='-O2 -Wall -pipe -g'
- echo "CFLAGS=$CFLAGS"
- echo "./configure $@"
diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest 
b/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest
deleted file mode 100755
index 58328bd3a50..000
--- a/meta/recipes-multimedia/alsa/alsa-tools/gitcompile_hdajacksensetest

[OE-core] [PATCH 2/3] gcc8: drop stray uClibc specific patch

[Khem Raj]

From: Andre McCurdy 

The patch was previously removed for gcc7 but came back with gcc8.

  
http://git.openembedded.org/openembedded-core/commit/?id=f71bc69e5b7581c53071055b694bb0dbfe4b4a87

Signed-off-by: Andre McCurdy 
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-8.1.inc |  1 -
 .../gcc/gcc-8.1/0002-c99-snprintf.patch   | 28 ---
 2 files changed, 29 deletions(-)
 delete mode 100644 meta/recipes-devtools/gcc/gcc-8.1/0002-c99-snprintf.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.1.inc 
b/meta/recipes-devtools/gcc/gcc-8.1.inc
index cb0fbd9379..d83ba6555e 100644
--- a/meta/recipes-devtools/gcc/gcc-8.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.1.inc
@@ -32,7 +32,6 @@ BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.xz"
 SRC_URI = "\
${BASEURI} \
file://0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch \
-   file://0002-c99-snprintf.patch \
file://0003-gcc-poison-system-directories.patch \
file://0004-gcc-poison-dir-extend.patch \
file://0005-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch \
diff --git a/meta/recipes-devtools/gcc/gcc-8.1/0002-c99-snprintf.patch 
b/meta/recipes-devtools/gcc/gcc-8.1/0002-c99-snprintf.patch
deleted file mode 100644
index aa123b41a1..00
--- a/meta/recipes-devtools/gcc/gcc-8.1/0002-c99-snprintf.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 5fbfcf247ed6dd01263639daf0c9c3a291e2fd3a Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 29 Mar 2013 08:49:03 +0400
-Subject: [PATCH 02/39] c99-snprintf
-
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Pending

- libstdc++-v3/include/c_std/cstdio | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/libstdc++-v3/include/c_std/cstdio 
b/libstdc++-v3/include/c_std/cstdio
-index 1b9571eaa8d..ad816be4fd1 100644
 a/libstdc++-v3/include/c_std/cstdio
-+++ b/libstdc++-v3/include/c_std/cstdio
-@@ -144,7 +144,7 @@ namespace std
-   using ::vsprintf;
- } // namespace std
- 
--#if _GLIBCXX_USE_C99_STDIO
-+#if _GLIBCXX_USE_C99_STDIO || defined(__UCLIBC__)
- 
- #undef snprintf
- #undef vfscanf
--- 
-2.17.0
-
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] gcc-8: Fix spurious mcpu/march conflict for xscale

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-8.1.inc |  1 +
 ...003-build-failures-with-with-cpu-xsc.patch | 61 +++
 2 files changed, 62 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-8.1/0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.1.inc 
b/meta/recipes-devtools/gcc/gcc-8.1.inc
index d83ba6555e..c5f25f89ac 100644
--- a/meta/recipes-devtools/gcc/gcc-8.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.1.inc
@@ -73,6 +73,7 @@ SRC_URI = "\
${BACKPORTS} \
 "
 BACKPORTS = "\
+   
file://0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch \
 "
 SRC_URI[md5sum] = "65f7c65818dc540b3437605026d329fc"
 SRC_URI[sha256sum] = 
"1d1866f992626e61349a1ccd0b8d5253816222cdc13390dcfaa74b093aa2b153"
diff --git 
a/meta/recipes-devtools/gcc/gcc-8.1/0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch
 
b/meta/recipes-devtools/gcc/gcc-8.1/0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch
new file mode 100644
index 00..68b8962d47
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-8.1/0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch
@@ -0,0 +1,61 @@
+From 11dc6b9576b78bb7a8d70491beab7ab4de24c9d0 Mon Sep 17 00:00:00 2001
+From: rearnsha 
+Date: Mon, 4 Jun 2018 08:46:04 +
+Subject: [PATCH] [arm] PR target/86003 build failures with --with-cpu=xscale
+
+The XScale cpu configuration in GCC has always been somewhat
+non-conforming.  Although XScale isn't an architecture (it's simply an
+implementation of ARMv5te), we do by tradition emit a specific
+pre-define for it.  We achieve this effect by adding an additional
+feature bit to the xscale CPU definition that isn't part of the base
+architecture.
+
+When I restructured the options last year I overlooked this oddity and
+the result, of course, is that this configuration now fails to build
+as intended.
+
+What happens is that the driver (correctly) constructs an architecture
+for the xscale cpu name (as armv5te) and passes it in addition to the
+CPU name.  The backend code, on finding both a cpu and an architecture
+specifies attempts to correlate the two and finds a difference due to
+the additional feature bit and reports an inconsistency (fatally if
+-werror is specified).
+
+I think the best fix to this is to treat the xscale feature bit using
+the same mechanism that we use for other 'quirks' in CPU
+implementations and simply filter it out before comparing the
+capabilities.  It has the additional benefit that it's also the
+simplest fix.
+
+   PR target/86003
+   * config/arm/arm-cpus.in (ALL_QUIRKS): Add xscale feature to the list
+   of bits to ignore when comparing architectures.
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-8-branch@261141 
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+Signed-off-by: Khem Raj 
+Upstream-Status: Backport
+
+ gcc/ChangeLog  | 6 ++
+ gcc/config/arm/arm-cpus.in | 4 +++-
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
+index 96972a057e7..545321b0bbe 100644
+--- a/gcc/config/arm/arm-cpus.in
 b/gcc/config/arm/arm-cpus.in
+@@ -268,7 +268,9 @@ define fgroup DOTPROD  NEON dotprod
+ 
+ # List of all quirk bits to strip out when comparing CPU features with
+ # architectures.
+-define fgroup ALL_QUIRKS   quirk_no_volatile_ce quirk_armv6kz quirk_cm3_ldrd
++# xscale isn't really a 'quirk', but it isn't an architecture either and we
++# need to ignore it for matching purposes.
++define fgroup ALL_QUIRKS   quirk_no_volatile_ce quirk_armv6kz quirk_cm3_ldrd 
xscale
+ 
+ # Architecture entries
+ # format:
+-- 
+2.17.1
+
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] mesa: Enable gallium-llvm on x86 and x86_64

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-graphics/cairo/cairo.inc | 3 ++-
 meta/recipes-graphics/mesa/mesa.inc   | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cairo/cairo.inc 
b/meta/recipes-graphics/cairo/cairo.inc
index 20e0d2c92a..7347f223ff 100644
--- a/meta/recipes-graphics/cairo/cairo.inc
+++ b/meta/recipes-graphics/cairo/cairo.inc
@@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
 DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb', 
'', d)} \
-   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
+   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'opengl', '', 
d)}"
 
 PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no 
--disable-xlib,${X11DEPENDS}"
 PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index fa99f7d50c..d1723e3506 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -45,6 +45,9 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 
'wayland vulkan', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 
'dri3', '', d)} \
   "
 
+PACKAGECONFIG_append_x86 = " gallium-llvm gallium r600"
+PACKAGECONFIG_append_x86-64 = " gallium-llvm gallium r600"
+
 # "gbm" requires "dri", "opengl"
 PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
 
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] GCC fixes and enable llvmpipe in mesa for x86

[Khem Raj]

Fixes gcc for xscale march/mcpu issue
Drop redundant patch
enable llvmpipe for mesa

The following changes since commit 8ab5b439ea82ac775494a0ce7a6f3615b61c94be:

  linux-yocto/4.14/4.15: fix gcc8 mips compilation issues (2018-06-11 23:38:17 
+0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib kraj/master
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/master

Andre McCurdy (1):
  gcc8: drop stray uClibc specific patch

Khem Raj (2):
  mesa: Enable gallium-llvm on x86 and x86_64
  gcc-8: Fix spurious mcpu/march conflict for xscale

 meta/recipes-devtools/gcc/gcc-8.1.inc |  2 +-
 .../gcc/gcc-8.1/0002-c99-snprintf.patch   | 28 -
 ...003-build-failures-with-with-cpu-xsc.patch | 61 +++
 meta/recipes-graphics/cairo/cairo.inc |  3 +-
 meta/recipes-graphics/mesa/mesa.inc   |  3 +
 5 files changed, 67 insertions(+), 30 deletions(-)
 delete mode 100644 meta/recipes-devtools/gcc/gcc-8.1/0002-c99-snprintf.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc-8.1/0041-arm-PR-target-86003-build-failures-with-with-cpu-xsc.patch

-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Khem Raj]

On Fri, Jun 15, 2018 at 3:41 AM Herve Jourdain  wrote:
>
> Hi,
>
> Actually, I meant "works" in the sense of "does compile" - as opposed to 
> armv8 where it does not compile, which is why we're having this discussion in 
> the first place.
> So I was merely suggesting to not modify previous oe behavior for the db 
> package for previous architectures, and just add the removal of 'swp' for 
> armv8, where it matters most.
>
> If we want to look at it in details, based on the "ARM Architecture Reference 
> Manual ARMv7-A and ARMv7-R edition":
> 1. SWP is the way to go before ARMv6.
> 2. SWP has been deprecated in ARMv6.
> 3. SWP has been deprecated AND made optional in ARMv7ve.
> 4. "The SWP and SWPB instructions rely on the properties of the system beyond 
> the processor to ensure that no stores from other observers can occur between 
> the load access and the store access, and this might not be implemented for 
> all regions of memory on some system implementations. In all cases, SWP and 
> SWPB do ensure that no stores from the processor that executed the SWP or 
> SWPB instruction can occur between the load access and the store access of 
> the SWP or SWPB."
>
> This latest part means that it may or may not work in SMP environments, it 
> depends on how the system is architecture around the cores - most likely how 
> the bus system is designed I believe. So it may actually be working fine if 
> the system/bus designer has taken that into account.
>
> This said, I believe that from point #3 above, it might make sense to disable 
> SWP for armv7ve as well, since being optional means that it might be compiled 
> correctly, but still fail at runtime, depending on the choices of the SoC 
> manufacturer.
> So my recommendation would be to add:
> MUTEX_armv7ve = ""
> MUTEX_armv8 = ""
>
> To disable 'swp' by default only for those 2 archs, while keeping things like 
> they are for previous architectures.
>

the least intrusive fix it to fix what we need and let the defaults be
as it in this case.

> Cheers,
> Herve
>
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: vendredi 15 juin 2018 09:39
> To: Herve Jourdain 
> Cc: Khem Raj ; Ovidiu Panait 
> ; Patches and discussions about the oe-core 
> layer 
> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>
> On Fri, Jun 15, 2018 at 12:10 AM, Herve Jourdain  
> wrote:
> > Hi,
> >
> > So the issue is whether we want to change the behaviour of previous 
> > architectures, or if we try to fix the issue only for the architectures 
> > that don't work.
> > Until now, the db recipe was enabling the 'swp' optimization, and that 
> > behavior could be disabled on .bbappend if needed.
> > While that works fine until armv7ve, it does not work for armv8, which has 
> > removed support for those instructions.
>
> I don't know if "works fine until armv7ve" is correct. Although the swp 
> instruction exists for armv7, according to the link I posted yesterday, it is 
> not guaranteed to work.
>
>   
> https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
>
> Or do you have other evidence to suggest that swp is safe to use for armv7?
>
> > Therefore, there is a need to fix it for armv8 - and armv8 only - whereas 
> > it can be safely used on previous architectures.
> > If we remove the use for all ARM architectures, that might create some 
> > regression/issues.
> > If we just remove the use of 'swp' only for armv8, we ensure it doesn't 
> > break anything that's running on previous ARM architectures.
> >
> > Cheers,
> > Herve
> >
> > -Original Message-
> > From: Andre McCurdy [mailto:armccu...@gmail.com]
> > Sent: vendredi 15 juin 2018 00:03
> > To: Khem Raj 
> > Cc: Herve Jourdain ; Ovidiu Panait
> > ; Patches and discussions about the
> > oe-core layer 
> > Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex
> > code
> >
> > On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
> >> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
> >>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
> >>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
> >>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> I believe I solved that same problem by just adding, in the
> >>> >> >> case of
> >>> >> >> armv8
> >>> >> >> (which I believe may be the new architecture you're referring to):
> >>> >> >> MUTEX_armv8 = ""
> >>> >> >> This way, it allows previous versions to work just like they
> >>> >> >> did before, without having to disable ARM assembler mutex code
> >>> >> >> for architectures that support it correctly - up to armv7ve I
> >>> >> >> believe.
> >>> >> >> Of course, we might need to also have a good definition for
> >>> >> >> armv8, which is the object of another thread.
> >>> >> >
> >>> >> > right thats a better approach.
> >>> >>
> 

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Herve Jourdain]

Hi,

Actually, I meant "works" in the sense of "does compile" - as opposed to armv8 
where it does not compile, which is why we're having this discussion in the 
first place.
So I was merely suggesting to not modify previous oe behavior for the db 
package for previous architectures, and just add the removal of 'swp' for 
armv8, where it matters most.

If we want to look at it in details, based on the "ARM Architecture Reference 
Manual ARMv7-A and ARMv7-R edition":
1. SWP is the way to go before ARMv6.
2. SWP has been deprecated in ARMv6.
3. SWP has been deprecated AND made optional in ARMv7ve.
4. "The SWP and SWPB instructions rely on the properties of the system beyond 
the processor to ensure that no stores from other observers can occur between 
the load access and the store access, and this might not be implemented for all 
regions of memory on some system implementations. In all cases, SWP and SWPB do 
ensure that no stores from the processor that executed the SWP or SWPB 
instruction can occur between the load access and the store access of the SWP 
or SWPB."

This latest part means that it may or may not work in SMP environments, it 
depends on how the system is architecture around the cores - most likely how 
the bus system is designed I believe. So it may actually be working fine if the 
system/bus designer has taken that into account.

This said, I believe that from point #3 above, it might make sense to disable 
SWP for armv7ve as well, since being optional means that it might be compiled 
correctly, but still fail at runtime, depending on the choices of the SoC 
manufacturer.
So my recommendation would be to add:
MUTEX_armv7ve = ""
MUTEX_armv8 = ""

To disable 'swp' by default only for those 2 archs, while keeping things like 
they are for previous architectures.

Cheers,
Herve

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: vendredi 15 juin 2018 09:39
To: Herve Jourdain 
Cc: Khem Raj ; Ovidiu Panait ; 
Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

On Fri, Jun 15, 2018 at 12:10 AM, Herve Jourdain  wrote:
> Hi,
>
> So the issue is whether we want to change the behaviour of previous 
> architectures, or if we try to fix the issue only for the architectures that 
> don't work.
> Until now, the db recipe was enabling the 'swp' optimization, and that 
> behavior could be disabled on .bbappend if needed.
> While that works fine until armv7ve, it does not work for armv8, which has 
> removed support for those instructions.

I don't know if "works fine until armv7ve" is correct. Although the swp 
instruction exists for armv7, according to the link I posted yesterday, it is 
not guaranteed to work.

  
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers

Or do you have other evidence to suggest that swp is safe to use for armv7?

> Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
> can be safely used on previous architectures.
> If we remove the use for all ARM architectures, that might create some 
> regression/issues.
> If we just remove the use of 'swp' only for armv8, we ensure it doesn't break 
> anything that's running on previous ARM architectures.
>
> Cheers,
> Herve
>
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: vendredi 15 juin 2018 00:03
> To: Khem Raj 
> Cc: Herve Jourdain ; Ovidiu Panait 
> ; Patches and discussions about the 
> oe-core layer 
> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex 
> code
>
> On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
>> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
>>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
>>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy 
>>> > 
>>> > wrote:
>>> >>
>>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
>>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>>> >> >> Hi,
>>> >> >>
>>> >> >> I believe I solved that same problem by just adding, in the 
>>> >> >> case of
>>> >> >> armv8
>>> >> >> (which I believe may be the new architecture you're referring to):
>>> >> >> MUTEX_armv8 = ""
>>> >> >> This way, it allows previous versions to work just like they 
>>> >> >> did before, without having to disable ARM assembler mutex code 
>>> >> >> for architectures that support it correctly - up to armv7ve I 
>>> >> >> believe.
>>> >> >> Of course, we might need to also have a good definition for 
>>> >> >> armv8, which is the object of another thread.
>>> >> >
>>> >> > right thats a better approach.
>>> >>
>>> >> SWP is not guaranteed to work on SMP systems... and even if it 
>>> >> does, performance is likely to be worse than the pthreads version 
>>> >> (which can take advantage of the newer instructions).
>>> >>
>>> >>
>>> >> https://community.arm.com/processors/b/blog/posts/locks-swps-and-
>>> >> t
>>> >> wo-smoking-barriers
>>> >>
>>> >> In general, use of 

Re: [OE-core] [PATCH 2/7] openssh: stop manually hiding libutil etc headers from configure

[Richard Purdie]

On Thu, 2018-06-07 at 11:48 -0700, Andre McCurdy wrote:
> Since we now have recipe specific sysroots, drop old workarounds
> for non-deterministic detection of sysroot header files.
> 
> Signed-off-by: Andre McCurdy 
> ---
>  meta/recipes-connectivity/openssh/openssh_7.7p1.bb | 8 
>  1 file changed, 8 deletions(-)

Even if we have rss, I think showing/documenting these recipes
configure scripts autodetect is a good thing so I'd prefer not to drop
this kind of code if it isn't causing problems.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3 1/5] arch-armv8a.inc: add tune include for armv8

[Nicolas Dechesne]

On Fri, Jun 15, 2018 at 5:22 AM, Randy Li  wrote:
> There are some addtional instructions apart from bare armv8,
> also there is armv8.1, armv8.2.
>
> Most the processor would support crc, except X-gene 1.
>
> Signed-off-by: Randy Li 
> ---
>  meta/conf/machine/include/arm/arch-armv8.inc  |  1 -
>  meta/conf/machine/include/arm/arch-armv8a.inc | 28 
> +++
>  2 files changed, 28 insertions(+), 1 deletion(-)
>  delete mode 100644 meta/conf/machine/include/arm/arch-armv8.inc

My previous comment still applies here. You can't just delete this
file. It's used by many BSP. and it's even used in oe-core itself:

layers/openembedded-core/meta/conf/machine/include/tune-thunderx.inc:require
conf/machine/include/arm/arch-armv8.inc
layers/openembedded-core/meta/conf/machine/qemuarm64.conf:require
conf/machine/include/arm/arch-armv8.inc

>  create mode 100644 meta/conf/machine/include/arm/arch-armv8a.inc
>
> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
> b/meta/conf/machine/include/arm/arch-armv8.inc
> deleted file mode 100644
> index 5e832fae6d..00
> --- a/meta/conf/machine/include/arm/arch-armv8.inc
> +++ /dev/null
> @@ -1 +0,0 @@
> -require conf/machine/include/arm/arch-arm64.inc
> diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
> b/meta/conf/machine/include/arm/arch-armv8a.inc
> new file mode 100644
> index 00..323d0d7f0f
> --- /dev/null
> +++ b/meta/conf/machine/include/arm/arch-armv8a.inc
> @@ -0,0 +1,28 @@
> +DEFAULTTUNE ?= "armv8a-crc"
> +
> +TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' 
> -march=armv8-a', '', d)}"
> +TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and 
> floating-point"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', 
> d)}"
> +TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check 
> (CRC)"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
> +TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '+crypto', 
> '', d)}"
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', 
> 'armv8a:', '' ,d)}"
> +
> +require conf/machine/include/arm/arch-arm64.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "armv8a armv8a-crc armv8a-crc-crypto armv8a-crypto"
> +ARMPKGARCH_tune-armv8a?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
> +ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
> +TUNE_FEATURES_tune-armv8a  = "aarch64 armv8a simd"
> +TUNE_FEATURES_tune-armv8a-crc  = "${TUNE_FEATURES_tune-armv8a} 
> crc"
> +TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
> crypto"
> +TUNE_FEATURES_tune-armv8a-crc-crypto   = 
> "${TUNE_FEATURES_tune-armv8a-crc} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
> --
> 2.14.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V3] ltp: set -fomit-frame-pointer explicitly for x86-64

[mingli.yu]

From: Mingli Yu 

Since ltp contains x86-64 assembler which uses the
frame-pointer register, it will trigger below error
when build ltp with -fno-omit-frame-pointer on
x86-64.
| cve-2015-3290.c: In function 'child_thread':
| cve-2015-3290.c:416:1: error: bp cannot be used in asm here

And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer on x86-64 for
compiler to fix the above build error.

Signed-off-by: Mingli Yu 
---
 meta/recipes-extended/ltp/ltp_20180515.bb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..21ff498 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,13 @@ LIC_FILES_CHKSUM = "\
 DEPENDS = "attr libaio libcap acl openssl zip-native"
 DEPENDS_append_libc-musl = " fts "
 EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# since ltp contains x86-64 assembler which uses the frame-pointer register,
+# set -fomit-frame-pointer x86-64 to handle cases where optimisation
+# is set to -O0 or frame pointers have been enabled by -fno-omit-frame-pointer
+# earlier in CFLAGS, etc.
+CFLAGS_append_x86-64 = " -fomit-frame-pointer"
+
 CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
 CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
 SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] ltp: set -fomit-frame-pointer explicitly for x86-64

[Yu, Mingli]

On 2018年06月15日 17:16, Richard Purdie wrote:

On Fri, 2018-06-15 at 17:01 +0800, mingli...@windriver.com wrote:

From: Mingli Yu 

When build ltp with -fno-omit-frame-pointer on
x86-64, it will trigger below error:

cve-2015-3290.c: In function 'child_thread':
cve-2015-3290.c:416:1: error: bp cannot be used in asm here


And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer on x86-64 for
compiler to fix the above build error.

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/ltp/ltp_20180515.bb | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..7fd8565 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,11 @@ LIC_FILES_CHKSUM = "\
  DEPENDS = "attr libaio libcap acl openssl zip-native"
  DEPENDS_append_libc-musl = " fts "
  EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# set -fomit-frame-pointer to handle cases where optimisation is set
to -O0 or frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in
CFLAGS, etc.
+CFLAGS_append_x86-64 = " -fomit-frame-pointer"
+
  CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
  CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
  SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"


Can you extend the comment to include:

"since ltp contains x86-64 assembler which uses the frame-pointer
register"

so that the comment doesn't just say what you're doing but why its
necessary only for x86-64


Thanks Richard!

It makes sense, will send out V3 to explain more why it's only necessary 
only for x86-64.


Thanks,



Cheers,

Richard




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] ltp: set -fomit-frame-pointer explicitly for x86-64

[Richard Purdie]

On Fri, 2018-06-15 at 17:01 +0800, mingli...@windriver.com wrote:
> From: Mingli Yu 
> 
> When build ltp with -fno-omit-frame-pointer on
> x86-64, it will trigger below error:
> > cve-2015-3290.c: In function 'child_thread':
> > cve-2015-3290.c:416:1: error: bp cannot be used in asm here
> 
> And there is also some comment as below in the source
> file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
> * Build with -O2.  Don't use -fno-omit-frame-pointer.
> 
> So explicitly set -fomit-frame-pointer on x86-64 for
> compiler to fix the above build error.
> 
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-extended/ltp/ltp_20180515.bb | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb
> b/meta/recipes-extended/ltp/ltp_20180515.bb
> index b07c1b9..7fd8565 100644
> --- a/meta/recipes-extended/ltp/ltp_20180515.bb
> +++ b/meta/recipes-extended/ltp/ltp_20180515.bb
> @@ -19,6 +19,11 @@ LIC_FILES_CHKSUM = "\
>  DEPENDS = "attr libaio libcap acl openssl zip-native"
>  DEPENDS_append_libc-musl = " fts "
>  EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
> +
> +# set -fomit-frame-pointer to handle cases where optimisation is set
> to -O0 or frame
> +# pointers have been enabled by -fno-omit-frame-pointer earlier in
> CFLAGS, etc.
> +CFLAGS_append_x86-64 = " -fomit-frame-pointer"
> +
>  CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
>  CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
>  SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"

Can you extend the comment to include:

"since ltp contains x86-64 assembler which uses the frame-pointer
register"

so that the comment doesn't just say what you're doing but why its
necessary only for x86-64

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] ltp: set -fomit-frame-pointer explicitly for x86-64

[mingli.yu]

From: Mingli Yu 

When build ltp with -fno-omit-frame-pointer on
x86-64, it will trigger below error:
| cve-2015-3290.c: In function 'child_thread':
| cve-2015-3290.c:416:1: error: bp cannot be used in asm here

And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer on x86-64 for
compiler to fix the above build error.

Signed-off-by: Mingli Yu 
---
 meta/recipes-extended/ltp/ltp_20180515.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..7fd8565 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,11 @@ LIC_FILES_CHKSUM = "\
 DEPENDS = "attr libaio libcap acl openssl zip-native"
 DEPENDS_append_libc-musl = " fts "
 EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# set -fomit-frame-pointer to handle cases where optimisation is set to -O0 or 
frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
+CFLAGS_append_x86-64 = " -fomit-frame-pointer"
+
 CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
 CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
 SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] boost: Improve reproducibility

[mingli.yu]

From: Mingli Yu 

Set .file section explicitly for .S files to avoid
the linker introduces the host path in symbols for
object files whose source file is .S
Otherwise, there is a host path in the symbols as
below:
$ readelf --wide --symbols 
/my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0
42:  0 FILE LOCAL DEFAULT ABS 
/my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/asm/make_x86_64_sysv_elf_gas.o

[YOCTO #12708]

Signed-off-by: Mingli Yu 
---
 ...e_x86_64_sysv_elf_gas.S-set-.file-section.patch | 48 ++
 meta/recipes-support/boost/boost_1.67.0.bb |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 
meta/recipes-support/boost/boost/0001-make_x86_64_sysv_elf_gas.S-set-.file-section.patch

diff --git 
a/meta/recipes-support/boost/boost/0001-make_x86_64_sysv_elf_gas.S-set-.file-section.patch
 
b/meta/recipes-support/boost/boost/0001-make_x86_64_sysv_elf_gas.S-set-.file-section.patch
new file mode 100644
index 000..c2ac49e
--- /dev/null
+++ 
b/meta/recipes-support/boost/boost/0001-make_x86_64_sysv_elf_gas.S-set-.file-section.patch
@@ -0,0 +1,48 @@
+From c99f798407e44c86e9f64f5b1adf3b4d0549eef2 Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Fri, 15 Jun 2018 16:21:56 +0800
+Subject: [PATCH] make_x86_64_sysv_elf_gas.S: set .file section
+
+Set .file section explicitly for .S files to avoid
+the linker introduces the host path in symbols for
+object files whose source file is .S
+Otherwise, there is a host path in the symbols as below:
+$ readelf --wide --symbols 
/my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0
+
+42:  0 FILE LOCAL DEFAULT ABS 
/my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/asm/make_x86_64_sysv_elf_gas.o
+
+Upstream-Status: Pending
+
+Signed-off-by: Mingli Yu 
+---
+ libs/context/src/asm/make_i386_sysv_elf_gas.S   | 1 +
+ libs/context/src/asm/make_x86_64_sysv_elf_gas.S | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/libs/context/src/asm/make_i386_sysv_elf_gas.S 
b/libs/context/src/asm/make_i386_sysv_elf_gas.S
+index de77e88..b76de26 100644
+--- a/libs/context/src/asm/make_i386_sysv_elf_gas.S
 b/libs/context/src/asm/make_i386_sysv_elf_gas.S
+@@ -24,6 +24,7 @@
+  *
  *
+  
/
+ 
++.file "make_i386_sysv_elf_gas.S"
+ .text
+ .globl make_fcontext
+ .align 2
+diff --git a/libs/context/src/asm/make_x86_64_sysv_elf_gas.S 
b/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
+index 25a0c00..0ef3756 100644
+--- a/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
 b/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
+@@ -24,6 +24,7 @@
+  *
  *
+  
/
+ 
++.file "make_x86_64_sysv_elf_gas.S"
+ .text
+ .globl make_fcontext
+ .type make_fcontext,@function
+-- 
+2.7.4
+
diff --git a/meta/recipes-support/boost/boost_1.67.0.bb 
b/meta/recipes-support/boost/boost_1.67.0.bb
index eb50899..7bb4511 100644
--- a/meta/recipes-support/boost/boost_1.67.0.bb
+++ b/meta/recipes-support/boost/boost_1.67.0.bb
@@ -7,4 +7,5 @@ SRC_URI += "\
 file://boost-math-disable-pch-for-gcc.patch \
 file://0001-Apply-boost-1.62.0-no-forced-flags.patch.patch \
 file://0003-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch \
+file://0001-make_x86_64_sysv_elf_gas.S-set-.file-section.patch \
 "
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: set -fomit-frame-pointer explicitly

[Yu, Mingli]

On 2018年06月15日 03:20, Andre McCurdy wrote:

On Thu, Jun 14, 2018 at 9:38 AM, Khem Raj  wrote:

On 6/14/18 2:35 AM, mingli...@windriver.com wrote:

From: Mingli Yu 

When build ltp with -fno-omit-frame-pointer,
it will trigger below error:
| cve-2015-3290.c: In function 'child_thread':
| cve-2015-3290.c:416:1: error: bp cannot be used in asm here

And there is also some comment as below in the source
file ltp/20180515-r0/git/testcases/cve/cve-2015-3290.c
* Build with -O2.  Don't use -fno-omit-frame-pointer.

So explicitly set -fomit-frame-pointer for compiler
to fix the above build error.

Signed-off-by: Mingli Yu 
---
  meta/recipes-extended/ltp/ltp_20180515.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20180515.bb 
b/meta/recipes-extended/ltp/ltp_20180515.bb
index b07c1b9..5ec25ed 100644
--- a/meta/recipes-extended/ltp/ltp_20180515.bb
+++ b/meta/recipes-extended/ltp/ltp_20180515.bb
@@ -19,6 +19,10 @@ LIC_FILES_CHKSUM = "\
  DEPENDS = "attr libaio libcap acl openssl zip-native"
  DEPENDS_append_libc-musl = " fts "
  EXTRA_OEMAKE_append_libc-musl = " LIBC=musl "
+
+# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or 
frame
+# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
+CFLAGS_append = " ${@bb.utils.contains('SELECTED_OPTIMIZATION', 
'-fno-omit-frame-pointer', '-fomit-frame-pointer', '', d)}"


This doesn't cover all cases - there may be times when the compiler
chooses to enable frame pointers without being called with
-fno-omit-frame-pointer.

You could make the append conditional on x86 though (based on the
error message, it's the x86 frame pointer register which is being used
by inline assembler).


Thanks Khem and Andre!

Considering it's x86-64 specific(x86 actually not affected), I will 
update the logic unconditionally in V2 as below only for x86-64 to cover 
some cases when the compiler enables frame pointers without being called 
with -fno-omit-frame-pointer.


CFLAGS_append_x86-64 = " -fomit-frame-pointer"

Thanks,




may be just append it unconditionally, what do we lose ?
CFLAGS += "-fomit-frame-pointer"


  CFLAGS_append_powerpc64 = " -D__SANE_USERSPACE_TYPES__"
  CFLAGS_append_mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
  SRCREV = "96cbf48313afa65ef4d693d3441cbfd60a8d9b27"





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] coreutils: fix nativesdk install failure

[S. Lockwood-Childs]

The change "fix hostname conflict with other packages" moved the
hostname util to the list of base_bindir_progs, so do_install_append()
now expects hostname to have been built.

coreutils do_install_append() is shared between target and nativesdk
builds (though not used by native build, see comment) so hostname should
be enabled to build on both of them.

Signed-off-by: S. Lockwood-Childs 
---
 meta/recipes-core/coreutils/coreutils_8.29.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/coreutils/coreutils_8.29.bb 
b/meta/recipes-core/coreutils/coreutils_8.29.bb
index 0b8acc5..4704f32 100644
--- a/meta/recipes-core/coreutils/coreutils_8.29.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.29.bb
@@ -26,7 +26,7 @@ SRC_URI[sha256sum] = 
"92d0fa1c311cacefa89853bdb53c62f4110cdfda3820346b59cbd098f4
 
 EXTRA_OECONF_class-native = "--without-gmp"
 EXTRA_OECONF_class-target = "--enable-install-program=arch,hostname 
--libexecdir=${libdir}"
-EXTRA_OECONF_class-nativesdk = "--enable-install-program=arch"
+EXTRA_OECONF_class-nativesdk = "--enable-install-program=arch,hostname"
 
 # acl and xattr are not default features
 #
-- 
1.9.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] sqlite3: consistent set of features for nativesdk

[S. Lockwood-Childs]

Enable use of pread() and enable column metadata API for nativesdk builds.
This brings nativesdk in line with target and native builds.
---
 meta/recipes-support/sqlite/sqlite3.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/sqlite/sqlite3.inc 
b/meta/recipes-support/sqlite/sqlite3.inc
index 95ec89c..30847b9 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -37,10 +37,12 @@ CFLAGS_append = " -fPIC"
 
 # pread() is in POSIX.1-2001 so any reasonable system must surely support it
 BUILD_CFLAGS += "-DUSE_PREAD"
+BUILDSDK_CFLAGS += "-DUSE_PREAD"
 TARGET_CFLAGS += "-DUSE_PREAD"
 
 # Provide column meta-data API
 BUILD_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
+BUILDSDK_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
 TARGET_CFLAGS += "-DSQLITE_ENABLE_COLUMN_METADATA"
 
 PACKAGES = "lib${BPN} lib${BPN}-dev lib${BPN}-doc ${PN}-dbg 
lib${BPN}-staticdev ${PN}"
-- 
1.9.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] yocto-uninative: Update to version 2.1

[Richard Purdie]

This fixes issues with fontforge-native.

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/yocto-uninative.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index a8e82cb5d75..dcd59f87ccc 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -8,6 +8,6 @@
 
 UNINATIVE_MAXGLIBCVERSION = "2.27"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.9/;
-UNINATIVE_CHECKSUM[i686] ?= 
"83a4f927da81d9889ef0cbe5c12cb782e21c6cc11e6155600b94ff0c99576dce"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.1/;
+UNINATIVE_CHECKSUM[i686] ?= 
"a90db17d8845ece764aaac19348cd78504c0e554cb998da39ebad03aeef76185"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"d43555df8d5a056ef5b20c7d8e0287207974e09df1e969a3e19302c8b4ea6b4b"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Andre McCurdy]

On Fri, Jun 15, 2018 at 12:10 AM, Herve Jourdain  wrote:
> Hi,
>
> So the issue is whether we want to change the behaviour of previous 
> architectures, or if we try to fix the issue only for the architectures that 
> don't work.
> Until now, the db recipe was enabling the 'swp' optimization, and that 
> behavior could be disabled on .bbappend if needed.
> While that works fine until armv7ve, it does not work for armv8, which has 
> removed support for those instructions.

I don't know if "works fine until armv7ve" is correct. Although the
swp instruction exists for armv7, according to the link I posted
yesterday, it is not guaranteed to work.

  
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers

Or do you have other evidence to suggest that swp is safe to use for armv7?

> Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
> can be safely used on previous architectures.
> If we remove the use for all ARM architectures, that might create some 
> regression/issues.
> If we just remove the use of 'swp' only for armv8, we ensure it doesn't break 
> anything that's running on previous ARM architectures.
>
> Cheers,
> Herve
>
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: vendredi 15 juin 2018 00:03
> To: Khem Raj 
> Cc: Herve Jourdain ; Ovidiu Panait 
> ; Patches and discussions about the oe-core 
> layer 
> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code
>
> On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
>> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
>>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
>>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy
>>> > 
>>> > wrote:
>>> >>
>>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
>>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>>> >> >> Hi,
>>> >> >>
>>> >> >> I believe I solved that same problem by just adding, in the
>>> >> >> case of
>>> >> >> armv8
>>> >> >> (which I believe may be the new architecture you're referring to):
>>> >> >> MUTEX_armv8 = ""
>>> >> >> This way, it allows previous versions to work just like they
>>> >> >> did before, without having to disable ARM assembler mutex code
>>> >> >> for architectures that support it correctly - up to armv7ve I
>>> >> >> believe.
>>> >> >> Of course, we might need to also have a good definition for
>>> >> >> armv8, which is the object of another thread.
>>> >> >
>>> >> > right thats a better approach.
>>> >>
>>> >> SWP is not guaranteed to work on SMP systems... and even if it
>>> >> does, performance is likely to be worse than the pthreads version
>>> >> (which can take advantage of the newer instructions).
>>> >>
>>> >>
>>> >> https://community.arm.com/processors/b/blog/posts/locks-swps-and-t
>>> >> wo-smoking-barriers
>>> >>
>>> >> In general, use of hand optimised assembler mutex implementations
>>> >> in user space isn't something to be encouraged - use pthreads (or
>>> >> maybe a gcc intrinsic) instead.
>>> >>
>>> >
>>> > question is about disabling it on old arm machines, do we have data
>>> > where we know that other sync methods without swp works better on
>>> > armv5 and lower ?
>>>
>>> On armv5 and below a hand optimised implementation using SWP is
>>> likely to be faster than pthreads. No one is suggesting otherwise.
>>>
>>> On SMP (highly likely nowadays for armv7 and above), SWP simply might
>>> not work (aside from the fact that if it does work, it's likely to be
>>> slower than pthreads). It's not really a question of performance
>>> there, so the proposal to only disable SWP for armv8 doesn't seem
>>> like a safe solution.
>>
>> Suggestion is not to just do it for armv8 but To keep it there where
>> its beneficial
>
> You can always argue that micro optimisations are beneficial. The question is 
> whether they make a big enough difference in some real world use case to be 
> worth the maintenance effort.
>
>>> Using pthreads unconditionally is safe and easy. Unless you can prove
>>> that hand optimised SWP is really a big win for armv5 (is anyone
>>> really running a performance critical database on an armv5 system?)
>>> why not keep the recipe simple and use pthreads everywhere?
>>>
>>> >> I think the original patch is good.
>>> >>
>>> >> >> Cheers,
>>> >> >> Herve
>>> >> >>
>>> >> >> -Original Message-
>>> >> >> From: openembedded-core-boun...@lists.openembedded.org
>>> >> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On
>>> >> >> Behalf Of Ovidiu Panait
>>> >> >> Sent: jeudi 14 juin 2018 13:55
>>> >> >> To: openembedded-core@lists.openembedded.org
>>> >> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler
>>> >> >> mutex code
>>> >> >>
>>> >> >> The swpb in macro MUTEX_SET will cause "undefined instruction"
>>> >> >> error on the new arm arches which don't support this assembly
>>> >> >> instruction any more. If use ldrex/strex to replace swpb, the
>>> >> >> old arm arches don't support them. 

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Yu, Mingli]

On 2018年06月15日 14:54, Alexander Kanavin wrote:

Thanks! Mingli, can you try this please?


Sure,



Alex

2018-06-15 9:44 GMT+03:00 Khem Raj :



On 6/1/18 12:34 PM, Alexander Kanavin wrote:


On 06/01/2018 09:33 PM, Khem Raj wrote:


The .s file is not generated and it does not contain any .file
directives. The .o file also does not contain the path. It appears in
the final .so library at linking stage.



Can you share the linker cmdline ?



https://pastebin.com/WK9GVDfj

Note that of the three assembly-generated object files, only the path to
the first shows up in the .so - because of assembly labels I believe.



Thanks for sharing this. If there is a no file directive in an object file
then linker will use whatever is specified on linker cmdline so thats what
we see, We should define FILE symbol explicitly for .S files here, for C/C++
files compiler does that automatically.

Other files dont make a claim in final symbol table since this one file
alone has cross referencing to symbols from other objects.

Something like this will help


Thanks Khem very much!

Have set .file section in .S file as you suggested, it works.

Thanks,



Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
@@ -23,7 +23,7 @@
   *
--
*
   *  *

/
-
+.file "make_i386_sysv_elf_gas.S"
  .text
  .globl make_fcontext
  .align 2
Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
@@ -23,7 +23,7 @@
   *
--
*
   *  *

/
-
+.file "make_x86_64_sysv_elf_gas.S"
  .text
  .globl make_fcontext
  .type make_fcontext,@function



Alex


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Herve Jourdain]

Hi,

So the issue is whether we want to change the behaviour of previous 
architectures, or if we try to fix the issue only for the architectures that 
don't work.
Until now, the db recipe was enabling the 'swp' optimization, and that behavior 
could be disabled on .bbappend if needed.
While that works fine until armv7ve, it does not work for armv8, which has 
removed support for those instructions.
Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
can be safely used on previous architectures.
If we remove the use for all ARM architectures, that might create some 
regression/issues.
If we just remove the use of 'swp' only for armv8, we ensure it doesn't break 
anything that's running on previous ARM architectures.

Cheers,
Herve

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: vendredi 15 juin 2018 00:03
To: Khem Raj 
Cc: Herve Jourdain ; Ovidiu Panait 
; Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy 
>> > 
>> > wrote:
>> >>
>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I believe I solved that same problem by just adding, in the 
>> >> >> case of
>> >> >> armv8
>> >> >> (which I believe may be the new architecture you're referring to):
>> >> >> MUTEX_armv8 = ""
>> >> >> This way, it allows previous versions to work just like they 
>> >> >> did before, without having to disable ARM assembler mutex code 
>> >> >> for architectures that support it correctly - up to armv7ve I 
>> >> >> believe.
>> >> >> Of course, we might need to also have a good definition for 
>> >> >> armv8, which is the object of another thread.
>> >> >
>> >> > right thats a better approach.
>> >>
>> >> SWP is not guaranteed to work on SMP systems... and even if it 
>> >> does, performance is likely to be worse than the pthreads version 
>> >> (which can take advantage of the newer instructions).
>> >>
>> >>
>> >> https://community.arm.com/processors/b/blog/posts/locks-swps-and-t
>> >> wo-smoking-barriers
>> >>
>> >> In general, use of hand optimised assembler mutex implementations 
>> >> in user space isn't something to be encouraged - use pthreads (or 
>> >> maybe a gcc intrinsic) instead.
>> >>
>> >
>> > question is about disabling it on old arm machines, do we have data 
>> > where we know that other sync methods without swp works better on 
>> > armv5 and lower ?
>>
>> On armv5 and below a hand optimised implementation using SWP is 
>> likely to be faster than pthreads. No one is suggesting otherwise.
>>
>> On SMP (highly likely nowadays for armv7 and above), SWP simply might 
>> not work (aside from the fact that if it does work, it's likely to be 
>> slower than pthreads). It's not really a question of performance 
>> there, so the proposal to only disable SWP for armv8 doesn't seem 
>> like a safe solution.
>
> Suggestion is not to just do it for armv8 but To keep it there where 
> its beneficial

You can always argue that micro optimisations are beneficial. The question is 
whether they make a big enough difference in some real world use case to be 
worth the maintenance effort.

>> Using pthreads unconditionally is safe and easy. Unless you can prove 
>> that hand optimised SWP is really a big win for armv5 (is anyone 
>> really running a performance critical database on an armv5 system?) 
>> why not keep the recipe simple and use pthreads everywhere?
>>
>> >> I think the original patch is good.
>> >>
>> >> >> Cheers,
>> >> >> Herve
>> >> >>
>> >> >> -Original Message-
>> >> >> From: openembedded-core-boun...@lists.openembedded.org
>> >> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On 
>> >> >> Behalf Of Ovidiu Panait
>> >> >> Sent: jeudi 14 juin 2018 13:55
>> >> >> To: openembedded-core@lists.openembedded.org
>> >> >> Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler 
>> >> >> mutex code
>> >> >>
>> >> >> The swpb in macro MUTEX_SET will cause "undefined instruction" 
>> >> >> error on the new arm arches which don't support this assembly 
>> >> >> instruction any more. If use ldrex/strex to replace swpb, the 
>> >> >> old arm arches don't support them. So to avoid this issue, just 
>> >> >> disable the ARM assembler mutex code, and use the default 
>> >> >> pthreads mutex.
>> >> >>
>> >> >> Signed-off-by: Li Zhou 
>> >> >> Signed-off-by: Catalin Enache 
>> >> >> Signed-off-by: Ovidiu Panait 
>> >> >> ---
>> >> >>  meta/recipes-support/db/db_5.3.28.bb | 13 +
>> >> >>  1 file changed, 1 insertion(+), 12 deletions(-)
>> >> >>
>> >> >> diff --git a/meta/recipes-support/db/db_5.3.28.bb
>> >> >> b/meta/recipes-support/db/db_5.3.28.bb
>> >> >> index 

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Alexander Kanavin]

Thanks! Mingli, can you try this please?

Alex

2018-06-15 9:44 GMT+03:00 Khem Raj :
>
>
> On 6/1/18 12:34 PM, Alexander Kanavin wrote:
>>
>> On 06/01/2018 09:33 PM, Khem Raj wrote:

 The .s file is not generated and it does not contain any .file
 directives. The .o file also does not contain the path. It appears in
 the final .so library at linking stage.
>>>
>>>
>>> Can you share the linker cmdline ?
>>
>>
>> https://pastebin.com/WK9GVDfj
>>
>> Note that of the three assembly-generated object files, only the path to
>> the first shows up in the .so - because of assembly labels I believe.
>>
>
> Thanks for sharing this. If there is a no file directive in an object file
> then linker will use whatever is specified on linker cmdline so thats what
> we see, We should define FILE symbol explicitly for .S files here, for C/C++
> files compiler does that automatically.
>
> Other files dont make a claim in final symbol table since this one file
> alone has cross referencing to symbols from other objects.
>
> Something like this will help
>
> Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
> ===
> --- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S
> +++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
> @@ -23,7 +23,7 @@
>   *
> --
> *
>   *  *
>
> /
> -
> +.file "make_i386_sysv_elf_gas.S"
>  .text
>  .globl make_fcontext
>  .align 2
> Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
> ===
> --- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
> +++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
> @@ -23,7 +23,7 @@
>   *
> --
> *
>   *  *
>
> /
> -
> +.file "make_x86_64_sysv_elf_gas.S"
>  .text
>  .globl make_fcontext
>  .type make_fcontext,@function
>
>
>> Alex
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] boost: Improve reproducibility

[Khem Raj]

On 6/1/18 12:34 PM, Alexander Kanavin wrote:

On 06/01/2018 09:33 PM, Khem Raj wrote:

The .s file is not generated and it does not contain any .file
directives. The .o file also does not contain the path. It appears in
the final .so library at linking stage.


Can you share the linker cmdline ?


https://pastebin.com/WK9GVDfj

Note that of the three assembly-generated object files, only the path to 
the first shows up in the .so - because of assembly labels I believe.




Thanks for sharing this. If there is a no file directive in an object 
file then linker will use whatever is specified on linker cmdline so 
thats what we see, We should define FILE symbol explicitly for .S files 
here, for C/C++ files compiler does that automatically.


Other files dont make a claim in final symbol table since this one file 
alone has cross referencing to symbols from other objects.


Something like this will help

Index: boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_i386_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_i386_sysv_elf_gas.S
@@ -23,7 +23,7 @@
  * 
-- 
 *
  * 
 *


/
-
+.file "make_i386_sysv_elf_gas.S"
 .text
 .globl make_fcontext
 .align 2
Index: boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
===
--- boost_1_67_0.orig/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
+++ boost_1_67_0/libs/context/src/asm/make_x86_64_sysv_elf_gas.S
@@ -23,7 +23,7 @@
  * 
-- 
 *
  * 
 *


/
-
+.file "make_x86_64_sysv_elf_gas.S"
 .text
 .globl make_fcontext
 .type make_fcontext,@function


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core