* [PATCH v2] uninative: rebuild uninative for gcc 4.8 and 4.9
From: Ed Bartosh @ 2016-10-27 7:10 UTC (permalink / raw)
To: openembedded-core
Some c++ libraries fail to build if uninative is built
with gcc 5.x and host gcc version is either 4.8 or 4.9.
The issue should be solved by making separate uninative sstate
directory structure sstate-cache/universal-<gcc version> for host gcc
versions 4.8 and 4.9. This causes rebuilds of uninative if host gcc
is either 4.8 or 4.9 and it doesn't match gcc version used to build
uninative.
[YOCTO #10441]
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
---
meta/classes/uninative.bbclass | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 89cec07..45f9262 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -95,11 +95,25 @@ python uninative_event_enable() {
enable_uninative(d)
}
+def gcc_version(d):
+ compiler = d.getVar("BUILD_CC", True)
+ retval, output = oe.utils.getstatusoutput("%s --version" % compiler)
+ if retval:
+ bb.fatal("Error running %s --version: %s" % (compiler, output))
+
+ import re
+ match = re.match(".* (\d\.\d)\.\d .*", output.split('\n')[0])
+ if not match:
+ bb.fatal("Can't get compiler version from %s --version output" % compiler)
+
+ version = match.group(1)
+ return "-%s" % version if version in ("4.8", "4.9") else ""
+
def enable_uninative(d):
loader = d.getVar("UNINATIVE_LOADER", True)
if os.path.exists(loader):
bb.debug(2, "Enabling uninative")
- d.setVar("NATIVELSBSTRING", "universal")
+ d.setVar("NATIVELSBSTRING", "universal%s" % gcc_version(d))
d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
d.prependVar("PATH", "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
--
2.1.4
^ permalink raw reply related
* [PATCH 0/1] rpm: fix file location of rpm2cpio.real
From: Chen Qi @ 2016-10-27 7:49 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 0e651676817a0513abf50741d0ba28b35edbae09:
build-appliance-image: Update to master head revision (2016-10-26 09:33:40 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/rpm2cpio
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/rpm2cpio
Chen Qi (1):
rpm: fix file location of rpm2cpio.real
meta/recipes-devtools/rpm/rpm_5.4.16.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/1] rpm: fix file location of rpm2cpio.real
From: Chen Qi @ 2016-10-27 7:49 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477554547.git.Qi.Chen@windriver.com>
rpm2cpio is in ${PN}-common, but rpm2cpio.real is in ${PN}. This seperation
is really weird. Put them both in ${PN}-common.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
meta/recipes-devtools/rpm/rpm_5.4.16.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.16.bb b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
index 1332397..85eb5fe 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.16.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.16.bb
@@ -384,10 +384,10 @@ FILES_${PN} = "${bindir}/rpm \
${localstatedir}/lib/wdj \
${bindir}/rpm.real \
${bindir}/rpmconstant.real \
- ${bindir}/rpm2cpio.real \
"
FILES_${PN}-common = "${bindir}/rpm2cpio \
+ ${bindir}/rpm2cpio.real \
${bindir}/gendiff \
${sysconfdir}/rpm \
${localstatedir}/spool/repackage \
--
1.9.1
^ permalink raw reply related
* [PATCH][krogoth] db: let fix-parallel-build.patch apply again
From: Enrico Jorns @ 2016-10-27 8:06 UTC (permalink / raw)
To: openembedded-core
This patch fails to apply with quilt for the 6.0.30 version of db in
some cases. This issue is fixed in upstream, this is a minimal version
of the fix, adapted to krogoth stable branch.
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
---
meta/recipes-support/db/db/fix-parallel-build.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/db/db/fix-parallel-build.patch b/meta/recipes-support/db/db/fix-parallel-build.patch
index 2c7f1e1..14ed8be 100644
--- a/meta/recipes-support/db/db/fix-parallel-build.patch
+++ b/meta/recipes-support/db/db/fix-parallel-build.patch
@@ -8,7 +8,7 @@ Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
--- dist.orig/Makefile.in 2012-05-11 19:57:48.000000000 +0200
+++ dist/Makefile.in 2013-10-31 18:17:11.875532522 +0100
-@@ -1034,7 +1034,7 @@
+@@ -1041,7 +1041,7 @@
db_recover@o@ util_sig@o@ $(DEF_LIB) $(LIBS)
$(POSTLINK) $@
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 1/5] tiff: Security fix CVE-2016-3945
From: Yi Zhao @ 2016-10-27 9:41 UTC (permalink / raw)
To: Jussi Kukkonen; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAHiDW_FezY8Ee_VObh-n+kf_GCoOWWbwPGpVM6s_7htfv9UhmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9349 bytes --]
Hi Jussi,
在 2016年10月26日 17:09, Jussi Kukkonen 写道:
> On 26 October 2016 at 11:26, Yi Zhao <yi.zhao@windriver.com
> <mailto:yi.zhao@windriver.com>> wrote:
>
> CVE-2016-3945 libtiff: Multiple integer overflows in the (1)
> cvt_by_strip and (2) cvt_by_tile functions in the tiff2rgba tool in
> LibTIFF 4.0.6 and earlier, when -b mode is enabled, allow remote
> attackers to cause a denial of service (crash) or execute
> arbitrary code
> via a crafted TIFF image, which triggers an out-of-bounds write.
>
> External References:
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3945
> <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3945>
> http://bugzilla.maptools.org/show_bug.cgi?id=2545
> <http://bugzilla.maptools.org/show_bug.cgi?id=2545>
>
> Patch from:
> https://github.com/vadz/libtiff/commit/7c39352ccd9060d311d3dc9a1f1bc00133a160e6
> <https://github.com/vadz/libtiff/commit/7c39352ccd9060d311d3dc9a1f1bc00133a160e6>
>
> Signed-off-by: Yi Zhao <yi.zhao@windriver.com
> <mailto:yi.zhao@windriver.com>>
> ---
> .../libtiff/files/CVE-2016-3945.patch | 118
> +++++++++++++++++++++
> meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
> <http://tiff_4.0.6.bb> | 1 +
> 2 files changed, 119 insertions(+)
> create mode 100644
> meta/recipes-multimedia/libtiff/files/CVE-2016-3945.patch
>
> diff --git
> a/meta/recipes-multimedia/libtiff/files/CVE-2016-3945.patch
> b/meta/recipes-multimedia/libtiff/files/CVE-2016-3945.patch
> new file mode 100644
> index 0000000..4d965be
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/files/CVE-2016-3945.patch
> @@ -0,0 +1,118 @@
> +From 7c39352ccd9060d311d3dc9a1f1bc00133a160e6 Mon Sep 17 00:00:00
> 2001
> +From: erouault <erouault>
> +Date: Mon, 15 Aug 2016 20:06:40 +0000
> +Subject: [PATCH] * tools/tiff2rgba.c: Fix integer overflow in size of
> + allocated buffer, when -b mode is enabled, that could result in
> out-of-bounds
> + write. Based initially on patch tiff-CVE-2016-3945.patch from
> + libtiff-4.0.3-25.el7_2.src.rpm by Nikola Forro, with correction
> for invalid
> + tests that rejected valid files.
> +
> +CVE: CVE-2016-3945
> +Upstream-Status: Backport
> +https://github.com/vadz/libtiff/commit/7c39352ccd9060d311d3dc9a1f1bc00133a160e6
> <https://github.com/vadz/libtiff/commit/7c39352ccd9060d311d3dc9a1f1bc00133a160e6>
>
>
> It would be appropriate to point out that this is not the real
> upstream, just a nameless github user who maintains a git mirror of
> the libtiff repository. It's probably a reasonable choice -- the
> current libtiff situation with no real homepage, no real tarball
> hosting and a half-hidden cvs server for source control is pretty sad
> -- but should still be openly mentioned.
Thank you for your suggestion. This github is a mirror for libtiff cvs
repository in cvs.maptools.org. If the cvs repository is official, take
the patches from it is better.
Yi
>
> Jussi
>
> +
> +Signed-off-by: Yi Zhao <yi.zhao@windirver.com
> <mailto:yi.zhao@windirver.com>>
> +---
> + ChangeLog | 8 ++++++++
> + tools/tiff2rgba.c | 34 ++++++++++++++++++++++++++++++----
> + 2 files changed, 38 insertions(+), 4 deletions(-)
> +
> +diff --git a/ChangeLog b/ChangeLog
> +index 62dc1b5..9c0ab29 100644
> +--- a/ChangeLog
> ++++ b/ChangeLog
> +@@ -1,3 +1,11 @@
> ++2016-08-15 Even Rouault <even.rouault at spatialys.com
> <http://spatialys.com>>
> ++
> ++ * tools/tiff2rgba.c: Fix integer overflow in size of allocated
> ++ buffer, when -b mode is enabled, that could result in
> out-of-bounds
> ++ write. Based initially on patch tiff-CVE-2016-3945.patch from
> ++ libtiff-4.0.3-25.el7_2.src.rpm by Nikola Forro, with
> correction for
> ++ invalid tests that rejected valid files.
> ++
> + 2016-07-11 Even Rouault <even.rouault at spatialys.com
> <http://spatialys.com>>
> +
> + * tools/tiffcrop.c: Avoid access outside of stack
> allocated array
> +diff --git a/tools/tiff2rgba.c b/tools/tiff2rgba.c
> +index b7a81eb..16e3dc4 100644
> +--- a/tools/tiff2rgba.c
> ++++ b/tools/tiff2rgba.c
> +@@ -147,6 +147,7 @@ cvt_by_tile( TIFF *in, TIFF *out )
> + uint32 row, col;
> + uint32 *wrk_line;
> + int ok = 1;
> ++ uint32 rastersize, wrk_linesize;
> +
> + TIFFGetField(in, TIFFTAG_IMAGEWIDTH, &width);
> + TIFFGetField(in, TIFFTAG_IMAGELENGTH, &height);
> +@@ -163,7 +164,13 @@ cvt_by_tile( TIFF *in, TIFF *out )
> + /*
> + * Allocate tile buffer
> + */
> +- raster = (uint32*)_TIFFmalloc(tile_width * tile_height *
> sizeof (uint32));
> ++ rastersize = tile_width * tile_height * sizeof (uint32);
> ++ if (tile_width != (rastersize / tile_height) / sizeof( uint32))
> ++ {
> ++ TIFFError(TIFFFileName(in), "Integer overflow when
> calculating raster buffer");
> ++ exit(-1);
> ++ }
> ++ raster = (uint32*)_TIFFmalloc(rastersize);
> + if (raster == 0) {
> + TIFFError(TIFFFileName(in), "No space for raster buffer");
> + return (0);
> +@@ -173,7 +180,13 @@ cvt_by_tile( TIFF *in, TIFF *out )
> + * Allocate a scanline buffer for swapping during the vertical
> + * mirroring pass.
> + */
> +- wrk_line = (uint32*)_TIFFmalloc(tile_width * sizeof (uint32));
> ++ wrk_linesize = tile_width * sizeof (uint32);
> ++ if (tile_width != wrk_linesize / sizeof (uint32))
> ++ {
> ++ TIFFError(TIFFFileName(in), "Integer overflow when
> calculating wrk_line buffer");
> ++ exit(-1);
> ++ }
> ++ wrk_line = (uint32*)_TIFFmalloc(wrk_linesize);
> + if (!wrk_line) {
> + TIFFError(TIFFFileName(in), "No space for raster
> scanline buffer");
> + ok = 0;
> +@@ -249,6 +262,7 @@ cvt_by_strip( TIFF *in, TIFF *out )
> + uint32 row;
> + uint32 *wrk_line;
> + int ok = 1;
> ++ uint32 rastersize, wrk_linesize;
> +
> + TIFFGetField(in, TIFFTAG_IMAGEWIDTH, &width);
> + TIFFGetField(in, TIFFTAG_IMAGELENGTH, &height);
> +@@ -263,7 +277,13 @@ cvt_by_strip( TIFF *in, TIFF *out )
> + /*
> + * Allocate strip buffer
> + */
> +- raster = (uint32*)_TIFFmalloc(width * rowsperstrip * sizeof
> (uint32));
> ++ rastersize = width * rowsperstrip * sizeof (uint32);
> ++ if (width != (rastersize / rowsperstrip) / sizeof( uint32))
> ++ {
> ++ TIFFError(TIFFFileName(in), "Integer overflow when
> calculating raster buffer");
> ++ exit(-1);
> ++ }
> ++ raster = (uint32*)_TIFFmalloc(rastersize);
> + if (raster == 0) {
> + TIFFError(TIFFFileName(in), "No space for raster buffer");
> + return (0);
> +@@ -273,7 +293,13 @@ cvt_by_strip( TIFF *in, TIFF *out )
> + * Allocate a scanline buffer for swapping during the vertical
> + * mirroring pass.
> + */
> +- wrk_line = (uint32*)_TIFFmalloc(width * sizeof (uint32));
> ++ wrk_linesize = width * sizeof (uint32);
> ++ if (width != wrk_linesize / sizeof (uint32))
> ++ {
> ++ TIFFError(TIFFFileName(in), "Integer overflow when
> calculating wrk_line buffer");
> ++ exit(-1);
> ++ }
> ++ wrk_line = (uint32*)_TIFFmalloc(wrk_linesize);
> + if (!wrk_line) {
> + TIFFError(TIFFFileName(in), "No space for raster
> scanline buffer");
> + ok = 0;
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
> <http://tiff_4.0.6.bb>
> b/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb <http://tiff_4.0.6.bb>
> index 8147bc4..b978528 100644
> --- a/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
> <http://tiff_4.0.6.bb>
> +++ b/meta/recipes-multimedia/libtiff/tiff_4.0.6.bb
> <http://tiff_4.0.6.bb>
> @@ -10,6 +10,7 @@ SRC_URI =
> "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz
> <http://download.osgeo.org/libtiff/tiff-$%7BPV%7D.tar.gz> \
> file://CVE-2016-3186.patch \
> file://CVE-2016-5321.patch \
> file://CVE-2016-5323.patch \
> + file://CVE-2016-3945.patch \
> "
>
> SRC_URI[md5sum] = "d1d2e940dea0b5ad435f21f03d96dd72"
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>
>
[-- Attachment #2: Type: text/html, Size: 15585 bytes --]
^ permalink raw reply
* how to add new perl modules to stock OE build?
From: Robert P. J. Day @ 2016-10-27 9:52 UTC (permalink / raw)
To: OE Core mailing list
(followup to earlier thread, but now that i have a better idea of
what i'm trying to do, i decided to start a new thread that should be
more focused. apologies for dragging this out just a bit longer.)
as i posted earlier, i want to add some perl modules to a basic poky
build; in this case, building core-image-minimal for qemuppc, if that
makes any difference.
initially, i went hunting for existing recipes for the modules i
wanted (meta-perl, meta-cpan, ...), until i noticed that the perl
recipe directory contains a "perl-rdepends_5.22.1.inc" file, which as
i read it defines all of the modules to be incorporated into the
"perl-modules" package, so that *appears* to be the solution -- just
extend the set of modules to be built by extending the contents of
that file.
so, first, is that the recommended (or even correct) approach? as an
example, i want to add Text::Template; would that involve adding lines
similar to the following?
RDEPENDS_${PN}-module-text-template += "${PN}-module-exporter"
RDEPENDS_${PN}-module-text-template += "${PN}-module-strict"
RDEPENDS_${PN}-module-text-template += "${PN}-module-vars"
(not saying that would be the *complete* set of lines for that module,
only that that looks like a starting point.)
next, if that's a valid approach, i can see the code near the bottom
of perl_5.22.1.bb that appears to be taking care of creating the
perl-modules package:
===== start =====
# Create a perl-modules package recommending all the other perl
# packages (actually the non modules packages and not created too)
ALLOW_EMPTY_perl-modules = "1"
PACKAGES_append = " perl-modules "
PACKAGESPLITFUNCS_prepend = "split_perl_packages "
python split_perl_packages () {
libdir = d.expand('${libdir}/perl/${PV}')
do_split_packages(d, libdir, 'auto/([^.]*)/[^/]*\.(so|ld|ix|al)', 'perl-module-%s', 'perl module %s', recursive=True, match_path=True, prepend=False)
do_split_packages(d, libdir, 'Module/([^\/]*)\.pm', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
do_split_packages(d, libdir, 'Module/([^\/]*)/.*', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
do_split_packages(d, libdir, '(^(?!(CPAN\/|CPANPLUS\/|Module\/|unicore\/|auto\/)[^\/]).*)\.(pm|pl|e2x)', 'perl-module-%s', 'perl module %s', recursive=True, allow_dirs=False, match_path=True, prepend=False)
# perl-modules should recommend every perl module, and only the
# modules. Don't attempt to use the result of do_split_packages() as some
# modules are manually split (eg. perl-module-unicore).
packages = filter(lambda p: 'perl-module-' in p, d.getVar('PACKAGES', True).split())
d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' '.join(packages))
}
PACKAGES_DYNAMIC += "^perl-module-.*"
===== end =====
i sort of see what that's doing -- don't understand it completely,
but i'm assuming it's processing the contents of that .inc file to
list all modules to be built and incorporated into the "perl-modules"
dynamic package.
is this even remotely the right approach? is there an OE/YP manual
that explains this somewhere? thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Stefan Müller-Klieser @ 2016-10-27 11:44 UTC (permalink / raw)
To: Marek Vasut, Denys Dmytriyenko; +Cc: OE-core
In-Reply-To: <83c5347a-3962-7b3b-30d3-d5ee876fc2aa@denx.de>
On 25.10.2016 21:24, Marek Vasut wrote:
> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>
>>> Hi!
>>>
>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
>>>> <mailto:marex@denx.de>> wrote:
>>>>
>>>> Upgrade U-Boot to the latest version.
>>>>
>>>>
>>>> As usual, u-boot-mkimage broke again:
>>>
>>> That's weird, I successfully built it for nios2 during my tests.
>>> Can you tell me how I can replicate the issue , so I can test for it to
>>> prevent regression and roll out a patch ?
>>
>> Marek, Ross,
>>
>> Any progress on this? Need any help testing?
>>
> Yeah, how do you replicate this issue ?
>
Hi!
I am just looking at a similar problem and want to jump into the discussion.
As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
So to replicate the issue, you can use a bare minimum build host with no
cross toolchain installed, and I guess all targets will fail to build.
As this has been broken so many times, I want to discuss some possible fixes:
In the top level Makefile we have:
HOSTCC = cc
HOSTCFLAGS = ...
The problem is, you cannot properly override those variables, as they get used
a lot to do different things, e.g. in tools/Makefile we have (for cross tools
target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
Thats why we have the current workaround with a squashed override. I see many
possible solutions and would like to hear your opinion:
1. Make top level Makefile HOST assignments conditional "?="
- easy
- will probably not be accepted upstream
2. add "override" to appends in sublevel Makefiles
- adds complexity/one level of override hierarchy
3. Don't use appends for those variables (like in the kernel Makefile), overrides
in the recipe
- clean
- quite some rework in uboot
4. Hack around in the recipe with class overrides and exports
- quickfix, no patch required
- fails easily in the future
Any thoughts?
Stefan
^ permalink raw reply
* Re: how to add new perl modules to stock OE build?
From: Robert P. J. Day @ 2016-10-27 12:46 UTC (permalink / raw)
To: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610270533590.12908@localhost.localdomain>
ack ... never mind, i see my fundamental misunderstanding. i thought
all of the recipes being processed via the "perl-modules" package were
being (if necessary) downloaded from CPAN, or something like that,
then turned into installable rpms. i didn't look closely enough into
the perl source to see that all the modules listed in
"perl-rdepends_5.22.1.inc" are already in the perl source tree.
so i'm back to my original question -- what is the proper way to add
arbitrary perl modules to an image? if someone has a simple example of
how it's done, that'd be great. as proof-of-concept, i'd like to add
the Text::Template module to my "qemuppc" target.
thoughts? sorry for all the earlier noise, i thought i had it
figured out but ... no.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [master][morty][PATCH] uboot-sign: fix do_concat_dtb for .img, .rom
From: George McCollister @ 2016-10-27 13:13 UTC (permalink / raw)
To: OE-core
Now that out of tree building is enabled, ${B} must be used instead of
${S} as the path for UBOOT_BINARY.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
---
meta/classes/uboot-sign.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 3c56db8..cef26b1 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -68,8 +68,8 @@ do_concat_dtb () {
[ -e "${DEPLOYDIR}/${UBOOT_DTB_IMAGE}" ]; then
cd ${B}
oe_runmake EXT_DTB=${DEPLOYDIR}/${UBOOT_DTB_IMAGE}
- install ${S}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
- install ${S}/${UBOOT_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_IMAGE}
+ install ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
+ install ${B}/${UBOOT_BINARY} ${DEPLOY_DIR_IMAGE}/${UBOOT_IMAGE}
elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e "${DEPLOYDIR}/${UBOOT_DTB_IMAGE}" ]; then
cd ${DEPLOYDIR}
cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} | tee ${B}/${UBOOT_BINARY} > ${UBOOT_IMAGE}
--
2.8.0
^ permalink raw reply related
* Re: how to add new perl modules to stock OE build?
From: Olof Johansson @ 2016-10-27 13:26 UTC (permalink / raw)
To: Robert P. J. Day, OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610270833260.15014@localhost.localdomain>
On 16-10-27 08:46 -0400, Robert P. J. Day wrote:
>
> ack ... never mind, i see my fundamental misunderstanding. i thought
> all of the recipes being processed via the "perl-modules" package were
> being (if necessary) downloaded from CPAN, or something like that,
> then turned into installable rpms. i didn't look closely enough into
> the perl source to see that all the modules listed in
> "perl-rdepends_5.22.1.inc" are already in the perl source tree.
>
> so i'm back to my original question -- what is the proper way to add
> arbitrary perl modules to an image? if someone has a simple example of
> how it's done, that'd be great. as proof-of-concept, i'd like to add
> the Text::Template module to my "qemuppc" target.
>
> thoughts? sorry for all the earlier noise, i thought i had it
> figured out but ... no.
Hi,
Take a look at meta-perl in the meta-openembedded repository. It
contains a lot of recipes for Perl modules (Text::Template isn't
one of them though).
The cpan class in oe-core knows how to build Makefile.PL
(ExtUtils::MakeMaker) based perl modules (like Text::Template),
and cpan_build knows how to handle Build.PL (Module::Build) based
perl modules.
Note also the naming convention of perl-module-foo is used by
core modules (those shipped with perl itself); the convention
used for third party cpan modules is "libfoo-perl", e.g.
libtext-template-perl.
Hope this helps,
--
olofjn
^ permalink raw reply
* Re: how to add new perl modules to stock OE build?
From: Robert P. J. Day @ 2016-10-27 13:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: OE Core mailing list
In-Reply-To: <20161027132619.GJ20437@axis.com>
On Thu, 27 Oct 2016, Olof Johansson wrote:
> On 16-10-27 08:46 -0400, Robert P. J. Day wrote:
> >
> > ack ... never mind, i see my fundamental misunderstanding. i
> > thought all of the recipes being processed via the "perl-modules"
> > package were being (if necessary) downloaded from CPAN, or
> > something like that, then turned into installable rpms. i didn't
> > look closely enough into the perl source to see that all the
> > modules listed in "perl-rdepends_5.22.1.inc" are already in the
> > perl source tree.
> >
> > so i'm back to my original question -- what is the proper way to
> > add arbitrary perl modules to an image? if someone has a simple
> > example of how it's done, that'd be great. as proof-of-concept,
> > i'd like to add the Text::Template module to my "qemuppc" target.
> >
> > thoughts? sorry for all the earlier noise, i thought i had it
> > figured out but ... no.
>
> Hi,
>
> Take a look at meta-perl in the meta-openembedded repository. It
> contains a lot of recipes for Perl modules (Text::Template isn't one
> of them though).
yes, i *finally* clued in to how it's done ... i'll just start
whipping together recipes files for the modules i need, given that
most of them will be standard boilerplate, it shouldn't take that
long, just make a list and start writing.
> The cpan class in oe-core knows how to build Makefile.PL
> (ExtUtils::MakeMaker) based perl modules (like Text::Template), and
> cpan_build knows how to handle Build.PL (Module::Build) based perl
> modules.
yup, i noticed that, too.
> Note also the naming convention of perl-module-foo is used by core
> modules (those shipped with perl itself); the convention used for
> third party cpan modules is "libfoo-perl", e.g.
> libtext-template-perl.
ah, i was unaware of that, thanks. so i'll know how to name my
recipes now, thanks very much.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [PATCH] toaster: fix if USER_CLASSES is missing buildstats
From: Olaf Mandel @ 2016-10-27 16:37 UTC (permalink / raw)
To: openembedded-core; +Cc: Olaf Mandel
buildstats not being in USER_CLASSES is no reason to fail every
single task in toaster_collect_task_stats: using a non-existing
variable results in a None argument to os.path.join().
Check the variable availability before trying to use it.
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
---
meta/classes/toaster.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index 4bddf34..638bb39 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -157,11 +157,11 @@ python toaster_collect_task_stats() {
import bb.utils
import os
- toaster_statlist_file = os.path.join(e.data.getVar('BUILDSTATS_BASE', True), "toasterstatlist")
-
if not e.data.getVar('BUILDSTATS_BASE', True):
return # if we don't have buildstats, we cannot collect stats
+ toaster_statlist_file = os.path.join(e.data.getVar('BUILDSTATS_BASE', True), "toasterstatlist")
+
def stat_to_float(value):
return float(value.strip('% \n\r'))
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/2] update libsdl2 and taglib
From: Andreas Müller @ 2016-10-27 20:07 UTC (permalink / raw)
To: openembedded-core
v1 -> v2: descriptions changed as suggested by Alexander Kanavin
v2 -> v3: taglib build dynamic libraries instead of static
Andreas Müller (2):
libsdl2: update to 2.0.5
taglib: update to 1.11
...-sysroot-path-so-that-make-finds-our-wayl.patch | 32 ++++++++++++
...ideo-make-it-compatible-with-wayland-1.10.patch | 57 ----------------------
.../libsdl2/{libsdl2_2.0.4.bb => libsdl2_2.0.5.bb} | 14 +++---
.../taglib/{taglib_1.9.1.bb => taglib_1.11.bb} | 9 ++--
4 files changed, 46 insertions(+), 66 deletions(-)
create mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
delete mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-src-video-make-it-compatible-with-wayland-1.10.patch
rename meta/recipes-graphics/libsdl2/{libsdl2_2.0.4.bb => libsdl2_2.0.5.bb} (86%)
rename meta/recipes-support/taglib/{taglib_1.9.1.bb => taglib_1.11.bb} (67%)
--
2.5.5
^ permalink raw reply
* [PATCH v3 1/2] libsdl2: update to 2.0.5
From: Andreas Müller @ 2016-10-27 20:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477598840-1768-1-git-send-email-schnitzeltony@googlemail.com>
* 0001-src-video-make-it-compatible-with-wayland-1.10.patch is removed because
the problem has been resolved upstream
* Add 0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
so that WAYLAND_PROTOCOLS_SYSROOT_DIR is substituted in a way similar to gtk3
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
...-sysroot-path-so-that-make-finds-our-wayl.patch | 32 ++++++++++++
...ideo-make-it-compatible-with-wayland-1.10.patch | 57 ----------------------
.../libsdl2/{libsdl2_2.0.4.bb => libsdl2_2.0.5.bb} | 14 +++---
3 files changed, 40 insertions(+), 63 deletions(-)
create mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
delete mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-src-video-make-it-compatible-with-wayland-1.10.patch
rename meta/recipes-graphics/libsdl2/{libsdl2_2.0.4.bb => libsdl2_2.0.5.bb} (86%)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
new file mode 100644
index 0000000..d042430
--- /dev/null
+++ b/meta/recipes-graphics/libsdl2/libsdl2/0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch
@@ -0,0 +1,32 @@
+From b44808e43130dcd13b43e5b978b9b24aeb4c134c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@googlemail.com>
+Date: Thu, 20 Oct 2016 14:57:51 +0200
+Subject: [PATCH] prepend our sysroot path so that make finds our
+ wayland-protocol files
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
+---
+ configure.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.in b/configure.in
+index 726ded3..3376600 100644
+--- a/configure.in
++++ b/configure.in
+@@ -1206,7 +1206,7 @@ AC_HELP_STRING([--enable-video-wayland-qt-touch], [QtWayland server support for
+ WAYLAND_LIBS=`$PKG_CONFIG --libs wayland-client wayland-egl wayland-cursor xkbcommon`
+ WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
+ WAYLAND_CORE_PROTOCOL_DIR=`$PKG_CONFIG --variable=pkgdatadir wayland-client`
+- WAYLAND_PROTOCOLS_DIR=`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`
++ WAYLAND_PROTOCOLS_DIR=${WAYLAND_PROTOCOLS_SYSROOT_DIR}`$PKG_CONFIG --variable=pkgdatadir wayland-protocols`
+ video_wayland=yes
+ fi
+ fi
+--
+2.5.5
+
diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0001-src-video-make-it-compatible-with-wayland-1.10.patch b/meta/recipes-graphics/libsdl2/libsdl2/0001-src-video-make-it-compatible-with-wayland-1.10.patch
deleted file mode 100644
index 44e6d4d..0000000
--- a/meta/recipes-graphics/libsdl2/libsdl2/0001-src-video-make-it-compatible-with-wayland-1.10.patch
+++ /dev/null
@@ -1,57 +0,0 @@
-From b1ed3533433501ec52c8289a5b3a294e57e7f798 Mon Sep 17 00:00:00 2001
-From: Martin Jansa <martin.jansa@gmail.com>
-Date: Thu, 26 May 2016 11:31:52 +0000
-Subject: [PATCH] src/video: make it compatible with wayland 1.10
-
-| build/.libs/SDL_waylandevents.o: In function `wl_registry_bind':
-| /usr/include/wayland-client-protocol.h:305: undefined reference to `wl_proxy_marshal_constructor_versioned'
-| /usr/include/wayland-client-protocol.h:305: undefined reference to `wl_proxy_marshal_constructor_versioned'
-| build/.libs/SDL_waylandkeyboard.o: In function `wl_registry_bind':
-| /usr/include/wayland-client-protocol.h:305: undefined reference to `wl_proxy_marshal_constructor_versioned'
-| /usr/include/wayland-client-protocol.h:305: undefined reference to `wl_proxy_marshal_constructor_versioned'
-| build/.libs/SDL_waylandvideo.o: In function `wl_registry_bind':
-| /usr/include/wayland-client-protocol.h:305: undefined reference to `wl_proxy_marshal_constructor_versioned'
-| collect2: error: ld returned 1 exit status
-| make: *** [build/libSDL2.la] Error 1
-| ERROR: oe_runmake failed
-
-Upstream-Status: Pending
-Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
-
----
- src/video/wayland/SDL_waylanddyn.h | 1 +
- src/video/wayland/SDL_waylandsym.h | 4 ++++
- src/video/webos/SDL_waylanddyn.h | 1 +
- src/video/webos/SDL_waylandsym.h | 4 ++++
- 4 files changed, 10 insertions(+)
-
-diff --git a/src/video/wayland/SDL_waylanddyn.h b/src/video/wayland/SDL_waylanddyn.h
-index 8d9313a..c7b0157 100644
---- a/src/video/wayland/SDL_waylanddyn.h
-+++ b/src/video/wayland/SDL_waylanddyn.h
-@@ -79,6 +79,7 @@ void SDL_WAYLAND_UnloadSymbols(void);
- #define wl_proxy_get_user_data (*WAYLAND_wl_proxy_get_user_data)
- #define wl_proxy_add_listener (*WAYLAND_wl_proxy_add_listener)
- #define wl_proxy_marshal_constructor (*WAYLAND_wl_proxy_marshal_constructor)
-+#define wl_proxy_marshal_constructor_versioned (*WAYLAND_wl_proxy_marshal_constructor_versioned)
-
- #define wl_seat_interface (*WAYLAND_wl_seat_interface)
- #define wl_surface_interface (*WAYLAND_wl_surface_interface)
-diff --git a/src/video/wayland/SDL_waylandsym.h b/src/video/wayland/SDL_waylandsym.h
-index c3b4fa5..b9a0d97 100644
---- a/src/video/wayland/SDL_waylandsym.h
-+++ b/src/video/wayland/SDL_waylandsym.h
-@@ -55,6 +55,10 @@ SDL_WAYLAND_SYM(void, wl_list_insert_list, (struct wl_list *, struct wl_list *))
- SDL_WAYLAND_MODULE(WAYLAND_CLIENT_1_4)
- SDL_WAYLAND_SYM(struct wl_proxy *, wl_proxy_marshal_constructor, (struct wl_proxy *, uint32_t opcode, const struct wl_interface *interface, ...))
-
-+/* These functions are available in Wayland >= 1.10 */
-+SDL_WAYLAND_MODULE(WAYLAND_CLIENT_1_10)
-+SDL_WAYLAND_SYM(struct wl_proxy *, wl_proxy_marshal_constructor_versioned, (struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface, uint32_t version, ...))
-+
- SDL_WAYLAND_INTERFACE(wl_seat_interface)
- SDL_WAYLAND_INTERFACE(wl_surface_interface)
- SDL_WAYLAND_INTERFACE(wl_shm_pool_interface)
---
-1.9.1
-
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.4.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
similarity index 86%
rename from meta/recipes-graphics/libsdl2/libsdl2_2.0.4.bb
rename to meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
index 844ff33..ac7312b 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.4.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.5.bb
@@ -14,15 +14,16 @@ PROVIDES = "virtual/libsdl2"
DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender nativesdk-libxext', '', d)}"
-SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz \
- file://linkage.patch \
- file://0001-src-video-make-it-compatible-with-wayland-1.10.patch \
+SRC_URI = " \
+ http://www.libsdl.org/release/SDL2-${PV}.tar.gz \
+ file://linkage.patch \
+ file://0001-prepend-our-sysroot-path-so-that-make-finds-our-wayl.patch \
"
S = "${WORKDIR}/SDL2-${PV}"
-SRC_URI[md5sum] = "44fc4a023349933e7f5d7a582f7b886e"
-SRC_URI[sha256sum] = "da55e540bf6331824153805d58b590a29c39d2d506c6d02fa409aedeab21174b"
+SRC_URI[md5sum] = "d4055424d556b4a908aa76fad63abd3c"
+SRC_URI[sha256sum] = "442038cf55965969f2ff06d976031813de643af9c9edc9e331bd761c242e8785"
inherit autotools lib_package binconfig pkgconfig
@@ -31,7 +32,8 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
--disable-video-dummy \
--enable-pthreads \
--enable-sdl-dlopen \
- --disable-rpath"
+ --disable-rpath \
+ WAYLAND_PROTOCOLS_SYSROOT_DIR=${STAGING_DIR}/${MACHINE}"
# opengl packageconfig factored out to make it easy for distros
# and BSP layers to pick either (desktop) opengl, gles2, or no GL
--
2.5.5
^ permalink raw reply related
* [PATCH v3 2/2] taglib: update to 1.11
From: Andreas Müller @ 2016-10-27 20:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477598840-1768-1-git-send-email-schnitzeltony@googlemail.com>
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-support/taglib/{taglib_1.9.1.bb => taglib_1.11.bb} | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
rename meta/recipes-support/taglib/{taglib_1.9.1.bb => taglib_1.11.bb} (67%)
diff --git a/meta/recipes-support/taglib/taglib_1.9.1.bb b/meta/recipes-support/taglib/taglib_1.11.bb
similarity index 67%
rename from meta/recipes-support/taglib/taglib_1.9.1.bb
rename to meta/recipes-support/taglib/taglib_1.11.bb
index d125308..c29bda9 100644
--- a/meta/recipes-support/taglib/taglib_1.9.1.bb
+++ b/meta/recipes-support/taglib/taglib_1.11.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM = "file://COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c \
DEPENDS = "zlib"
SRC_URI = "http://taglib.github.io/releases/${BP}.tar.gz"
-SRC_URI[md5sum] = "0d35df96822bbd564c5504cb3c2e4d86"
-SRC_URI[sha256sum] = "72d371cd1419a87ae200447a53bff2be219283071e80fd12337928cc967dc71a"
+SRC_URI[md5sum] = "be39fa2054df40664cb557126ad7cf7c"
+SRC_URI[sha256sum] = "ed4cabb3d970ff9a30b2620071c2b054c4347f44fc63546dbe06f97980ece288"
UPSTREAM_CHECK_URI = "http://github.com/taglib/taglib/releases/"
@@ -21,7 +21,7 @@ inherit cmake pkgconfig binconfig-disabled
PACKAGES =+ "${PN}-c"
FILES_${PN}-c = "${libdir}/libtag_c.so.*"
-EXTRA_OECMAKE = "-DLIB_SUFFIX=${@d.getVar('baselib', True).replace('lib', '')}"
+EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON -DLIB_SUFFIX=${@d.getVar('baselib', True).replace('lib', '')}"
do_configure_prepend () {
rm -f ${S}/admin/ltmain.sh
@@ -30,3 +30,6 @@ do_configure_prepend () {
sed -i -e "s/atomic.hpp/atomic-not-exist.hpp/" ${S}/ConfigureChecks.cmake ${S}/taglib/toolkit/trefcounter.cpp
}
+# without -fPIC depending packages failed with many error like:
+# | <...>/ld: error: <...>/usr/lib/libtag.a(modfilebase.cpp.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
+CXXFLAGS += "-fPIC"
--
2.5.5
^ permalink raw reply related
* Re: [PATCH][master][krogoth] archiver: fix gcc-source handling
From: Wold, Saul @ 2016-10-27 20:32 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org,
richard.purdie@linuxfoundation.org, akuster@mvista.com
In-Reply-To: <1476124325-6771-1-git-send-email-sgw@linux.intel.com>
This has been merged to master ping for Krogoth
Sau!
On Mon, 2016-10-10 at 11:32 -0700, Saul Wold wrote:
>
> The source archiver was not handling the gcc-source target correctly,
> since it uses the
> work-shared directory, we don't want to unpack and patch it twice,
> just as the comments
> say, but the code was not there to check for the gcc-source target.
>
> [YOCTO #10265]
>
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>
> meta/classes/archiver.bbclass | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/archiver.bbclass
> b/meta/classes/archiver.bbclass
> index 1d8e863..9239983 100644
> --- a/meta/classes/archiver.bbclass
> +++ b/meta/classes/archiver.bbclass
> @@ -303,9 +303,10 @@ python do_unpack_and_patch() {
> return
> ar_outdir = d.getVar('ARCHIVER_OUTDIR', True)
> ar_workdir = d.getVar('ARCHIVER_WORKDIR', True)
> + pn = d.getVar('PN', True)
>
> # The kernel class functions require it to be on work-shared, so
> we dont change WORKDIR
> - if not bb.data.inherits_class('kernel-yocto', d):
> + if not (bb.data.inherits_class('kernel-yocto', d) or
> pn.startswith('gcc-source')):
> # Change the WORKDIR to make do_unpack do_patch run in
> another dir.
> d.setVar('WORKDIR', ar_workdir)
>
> @@ -323,7 +324,7 @@ python do_unpack_and_patch() {
> oe.path.copytree(src, src_orig)
>
> # Make sure gcc and kernel sources are patched only once
> - if not ((d.getVar('SRC_URI', True) == "" or
> bb.data.inherits_class('kernel-yocto', d))):
> + if not (d.getVar('SRC_URI', True) == "" or
> (bb.data.inherits_class('kernel-yocto', d) or pn.startswith('gcc-
> source'))):
> bb.build.exec_func('do_patch', d)
>
> # Create the patches
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH][master][krogoth] archiver: fix gcc-source handling
From: akuster808 @ 2016-10-27 21:36 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477600328.2097.1.camel@intel.com>
On 10/27/2016 01:32 PM, Wold, Saul wrote:
> This has been merged to master ping for Krogoth
>
> Sau!
is in my staging work.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akuster/krogoth-next&id=d52071671f6b93a7653b8445bf9bf2b9a5c0e29a
I am working on getting a clean build out of the AB before doing a pull
request. I suppose I should send a pre-pull request for review.
- armin
>
> On Mon, 2016-10-10 at 11:32 -0700, Saul Wold wrote:
>> The source archiver was not handling the gcc-source target correctly,
>> since it uses the
>> work-shared directory, we don't want to unpack and patch it twice,
>> just as the comments
>> say, but the code was not there to check for the gcc-source target.
>>
>> [YOCTO #10265]
>>
>> Signed-off-by: Saul Wold <sgw@linux.intel.com>
>> ---
>>
>> meta/classes/archiver.bbclass | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/archiver.bbclass
>> b/meta/classes/archiver.bbclass
>> index 1d8e863..9239983 100644
>> --- a/meta/classes/archiver.bbclass
>> +++ b/meta/classes/archiver.bbclass
>> @@ -303,9 +303,10 @@ python do_unpack_and_patch() {
>> return
>> ar_outdir = d.getVar('ARCHIVER_OUTDIR', True)
>> ar_workdir = d.getVar('ARCHIVER_WORKDIR', True)
>> + pn = d.getVar('PN', True)
>>
>> # The kernel class functions require it to be on work-shared, so
>> we dont change WORKDIR
>> - if not bb.data.inherits_class('kernel-yocto', d):
>> + if not (bb.data.inherits_class('kernel-yocto', d) or
>> pn.startswith('gcc-source')):
>> # Change the WORKDIR to make do_unpack do_patch run in
>> another dir.
>> d.setVar('WORKDIR', ar_workdir)
>>
>> @@ -323,7 +324,7 @@ python do_unpack_and_patch() {
>> oe.path.copytree(src, src_orig)
>>
>> # Make sure gcc and kernel sources are patched only once
>> - if not ((d.getVar('SRC_URI', True) == "" or
>> bb.data.inherits_class('kernel-yocto', d))):
>> + if not (d.getVar('SRC_URI', True) == "" or
>> (bb.data.inherits_class('kernel-yocto', d) or pn.startswith('gcc-
>> source'))):
>> bb.build.exec_func('do_patch', d)
>>
>> # Create the patches
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Marek Vasut @ 2016-10-28 0:18 UTC (permalink / raw)
To: Stefan Müller-Klieser, Denys Dmytriyenko; +Cc: OE-core
In-Reply-To: <5811E899.6050000@phytec.de>
On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
> On 25.10.2016 21:24, Marek Vasut wrote:
>> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>>
>>>> Hi!
>>>>
>>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
>>>>> <mailto:marex@denx.de>> wrote:
>>>>>
>>>>> Upgrade U-Boot to the latest version.
>>>>>
>>>>>
>>>>> As usual, u-boot-mkimage broke again:
>>>>
>>>> That's weird, I successfully built it for nios2 during my tests.
>>>> Can you tell me how I can replicate the issue , so I can test for it to
>>>> prevent regression and roll out a patch ?
>>>
>>> Marek, Ross,
>>>
>>> Any progress on this? Need any help testing?
>>>
>> Yeah, how do you replicate this issue ?
>>
> Hi!
Hi!
> I am just looking at a similar problem and want to jump into the discussion.
> As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
> So to replicate the issue, you can use a bare minimum build host with no
> cross toolchain installed, and I guess all targets will fail to build.
Well both ARM and nios2 builds for me, so I wonder what sort of stupid
thing am I doing.
> As this has been broken so many times, I want to discuss some possible fixes:
> In the top level Makefile we have:
> HOSTCC = cc
> HOSTCFLAGS = ...
> The problem is, you cannot properly override those variables, as they get used
> a lot to do different things, e.g. in tools/Makefile we have (for cross tools
> target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
> Thats why we have the current workaround with a squashed override. I see many
> possible solutions and would like to hear your opinion:
> 1. Make top level Makefile HOST assignments conditional "?="
> - easy
> - will probably not be accepted upstream
Why ?
> 2. add "override" to appends in sublevel Makefiles
> - adds complexity/one level of override hierarchy
> 3. Don't use appends for those variables (like in the kernel Makefile), overrides
> in the recipe
> - clean
> - quite some rework in uboot
Can you provide details ?
> 4. Hack around in the recipe with class overrides and exports
> - quickfix, no patch required
> - fails easily in the future
>
> Any thoughts?
> Stefan
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/1] rng-tools: add systemd service file
From: Dengke Du @ 2016-10-28 1:53 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <65f138952d1e0942e73bea4eca028650439bbfc9.1475211809.git.dengke.du@windriver.com>
Ping.
// Dengke
On 2016年09月30日 13:05, Dengke Du wrote:
> Add systemd service file for rng-tools.
>
> Signed-off-by: Dengke Du <dengke.du@windriver.com>
> ---
> meta/recipes-support/rng-tools/rng-tools/rngd.service | 9 +++++++++
> meta/recipes-support/rng-tools/rng-tools_5.bb | 14 ++++++++++++--
> 2 files changed, 21 insertions(+), 2 deletions(-)
> create mode 100644 meta/recipes-support/rng-tools/rng-tools/rngd.service
>
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> new file mode 100644
> index 0000000..b94ad50
> --- /dev/null
> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> @@ -0,0 +1,9 @@
> +[Unit]
> +Description=Hardware RNG Entropy Gatherer Daemon
> +
> +[Service]
> +ExecStart=@SBINDIR@/rngd -f -r /dev/urandom
> +SuccessExitStatus=66
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-support/rng-tools/rng-tools_5.bb b/meta/recipes-support/rng-tools/rng-tools_5.bb
> index 913a092..e9786f9 100644
> --- a/meta/recipes-support/rng-tools/rng-tools_5.bb
> +++ b/meta/recipes-support/rng-tools/rng-tools_5.bb
> @@ -8,7 +8,9 @@ SRC_URI = "http://heanet.dl.sourceforge.net/sourceforge/gkernel/${BP}.tar.gz \
> file://underquote.patch \
> file://uclibc-libuargp-configure.patch \
> file://init \
> - file://default"
> + file://default \
> + file://rngd.service \
> +"
>
> SRC_URI[md5sum] = "6726cdc6fae1f5122463f24ae980dd68"
> SRC_URI[sha256sum] = "60a102b6603bbcce2da341470cad42eeaa9564a16b4490e7867026ca11a3078e"
> @@ -20,7 +22,7 @@ python () {
> d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
> }
>
> -inherit autotools update-rc.d
> +inherit autotools update-rc.d systemd
>
> PACKAGECONFIG = "libgcrypt"
> PACKAGECONFIG_libc-musl = "libargp"
> @@ -40,7 +42,15 @@ do_install_append() {
> install -d "${D}${sysconfdir}/default"
> install -m 0644 ${WORKDIR}/default ${D}${sysconfdir}/default/rng-tools
> fi
> +
> + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
> + install -d ${D}${systemd_unitdir}/system
> + install -m 644 ${WORKDIR}/rngd.service ${D}${systemd_unitdir}/system
> + sed -i -e 's,@SBINDIR@,${sbindir},g' ${D}${systemd_unitdir}/system/rngd.service
> + fi
> }
>
> INITSCRIPT_NAME = "rng-tools"
> INITSCRIPT_PARAMS = "start 30 2 3 4 5 . stop 30 0 6 1 ."
> +
> +SYSTEMD_SERVICE_${PN} = "rngd.service"
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Denys Dmytriyenko @ 2016-10-28 2:11 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <ae855dd3-d95b-8616-8b6b-a3cf1f0a5275@denx.de>
On Fri, Oct 28, 2016 at 02:18:59AM +0200, Marek Vasut wrote:
> On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
> > On 25.10.2016 21:24, Marek Vasut wrote:
> >> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
> >>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
> >>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
> >>>>
> >>>> Hi!
> >>>>
> >>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
> >>>>> <mailto:marex@denx.de>> wrote:
> >>>>>
> >>>>> Upgrade U-Boot to the latest version.
> >>>>>
> >>>>>
> >>>>> As usual, u-boot-mkimage broke again:
> >>>>
> >>>> That's weird, I successfully built it for nios2 during my tests.
> >>>> Can you tell me how I can replicate the issue , so I can test for it to
> >>>> prevent regression and roll out a patch ?
> >>>
> >>> Marek, Ross,
> >>>
> >>> Any progress on this? Need any help testing?
> >>>
> >> Yeah, how do you replicate this issue ?
> >>
> > Hi!
>
> Hi!
>
> > I am just looking at a similar problem and want to jump into the discussion.
> > As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
> > So to replicate the issue, you can use a bare minimum build host with no
> > cross toolchain installed, and I guess all targets will fail to build.
>
> Well both ARM and nios2 builds for me, so I wonder what sort of stupid
> thing am I doing.
Well, that's the thing - your patches didn't change anything around toolchain,
so it shouldn't break what used to be working before, right? Unless it was
already broken...
Ross,
Care to elaborate on what is breaking for you and what setup you are using?
> > As this has been broken so many times, I want to discuss some possible fixes:
> > In the top level Makefile we have:
> > HOSTCC = cc
> > HOSTCFLAGS = ...
> > The problem is, you cannot properly override those variables, as they get used
> > a lot to do different things, e.g. in tools/Makefile we have (for cross tools
> > target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
> > Thats why we have the current workaround with a squashed override. I see many
> > possible solutions and would like to hear your opinion:
> > 1. Make top level Makefile HOST assignments conditional "?="
> > - easy
> > - will probably not be accepted upstream
>
> Why ?
Heh, good one! :)
> > 2. add "override" to appends in sublevel Makefiles
> > - adds complexity/one level of override hierarchy
> > 3. Don't use appends for those variables (like in the kernel Makefile), overrides
> > in the recipe
> > - clean
> > - quite some rework in uboot
>
> Can you provide details ?
>
> > 4. Hack around in the recipe with class overrides and exports
> > - quickfix, no patch required
> > - fails easily in the future
> >
> > Any thoughts?
> > Stefan
> >
>
>
> --
> Best regards,
> Marek Vasut
>
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Marek Vasut @ 2016-10-28 2:14 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: OE-core
In-Reply-To: <20161028021134.GK2494@denix.org>
On 10/28/2016 04:11 AM, Denys Dmytriyenko wrote:
> On Fri, Oct 28, 2016 at 02:18:59AM +0200, Marek Vasut wrote:
>> On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
>>> On 25.10.2016 21:24, Marek Vasut wrote:
>>>> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>>>>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>>>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
>>>>>>> <mailto:marex@denx.de>> wrote:
>>>>>>>
>>>>>>> Upgrade U-Boot to the latest version.
>>>>>>>
>>>>>>>
>>>>>>> As usual, u-boot-mkimage broke again:
>>>>>>
>>>>>> That's weird, I successfully built it for nios2 during my tests.
>>>>>> Can you tell me how I can replicate the issue , so I can test for it to
>>>>>> prevent regression and roll out a patch ?
>>>>>
>>>>> Marek, Ross,
>>>>>
>>>>> Any progress on this? Need any help testing?
>>>>>
>>>> Yeah, how do you replicate this issue ?
>>>>
>>> Hi!
>>
>> Hi!
>>
>>> I am just looking at a similar problem and want to jump into the discussion.
>>> As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
>>> So to replicate the issue, you can use a bare minimum build host with no
>>> cross toolchain installed, and I guess all targets will fail to build.
>>
>> Well both ARM and nios2 builds for me, so I wonder what sort of stupid
>> thing am I doing.
>
> Well, that's the thing - your patches didn't change anything around toolchain,
> so it shouldn't break what used to be working before, right? Unless it was
> already broken...
That's correct ... unless it got broken between 2016.03 and 2016.09 in
U-Boot upstream.
> Ross,
>
> Care to elaborate on what is breaking for you and what setup you are using?
Please do, indeed.
>>> As this has been broken so many times, I want to discuss some possible fixes:
>>> In the top level Makefile we have:
>>> HOSTCC = cc
>>> HOSTCFLAGS = ...
>>> The problem is, you cannot properly override those variables, as they get used
>>> a lot to do different things, e.g. in tools/Makefile we have (for cross tools
>>> target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
>>> Thats why we have the current workaround with a squashed override. I see many
>>> possible solutions and would like to hear your opinion:
>>> 1. Make top level Makefile HOST assignments conditional "?="
>>> - easy
>>> - will probably not be accepted upstream
>>
>> Why ?
>
> Heh, good one! :)
>
>
>>> 2. add "override" to appends in sublevel Makefiles
>>> - adds complexity/one level of override hierarchy
>>> 3. Don't use appends for those variables (like in the kernel Makefile), overrides
>>> in the recipe
>>> - clean
>>> - quite some rework in uboot
>>
>> Can you provide details ?
>>
>>> 4. Hack around in the recipe with class overrides and exports
>>> - quickfix, no patch required
>>> - fails easily in the future
>>>
>>> Any thoughts?
>>> Stefan
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut
>>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/4] u-boot: Update to 2016.09.01 release
From: Khem Raj @ 2016-10-28 4:23 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <ae855dd3-d95b-8616-8b6b-a3cf1f0a5275@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3560 bytes --]
> On Oct 27, 2016, at 5:18 PM, Marek Vasut <marex@denx.de> wrote:
>
> On 10/27/2016 01:44 PM, Stefan Müller-Klieser wrote:
>> On 25.10.2016 21:24, Marek Vasut wrote:
>>> On 10/25/2016 08:32 PM, Denys Dmytriyenko wrote:
>>>> On Sat, Oct 22, 2016 at 10:32:12PM +0200, Marek Vasut wrote:
>>>>> On 10/21/2016 09:47 AM, Burton, Ross wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>>> On 20 October 2016 at 14:35, Marek Vasut <marex@denx.de
>>>>>> <mailto:marex@denx.de>> wrote:
>>>>>>
>>>>>> Upgrade U-Boot to the latest version.
>>>>>>
>>>>>>
>>>>>> As usual, u-boot-mkimage broke again:
>>>>>
>>>>> That's weird, I successfully built it for nios2 during my tests.
>>>>> Can you tell me how I can replicate the issue , so I can test for it to
>>>>> prevent regression and roll out a patch ?
>>>>
>>>> Marek, Ross,
>>>>
>>>> Any progress on this? Need any help testing?
>>>>
>>> Yeah, how do you replicate this issue ?
>>>
>> Hi!
>
> Hi!
>
>> I am just looking at a similar problem and want to jump into the discussion.
>> As Ross said, the problem is to not respect host/target -- cc/cflags/ldflags.
>> So to replicate the issue, you can use a bare minimum build host with no
>> cross toolchain installed, and I guess all targets will fail to build.
>
> Well both ARM and nios2 builds for me, so I wonder what sort of stupid
> thing am I doing.
perhaps, its manifesting when toolchain is used from sstate, moreover the sstate
comes from a mirror which is populated from a workspace which has different
build time paths, which means its encoding a different default sysroot into
toolchain. So unless you add TOOLCHAIN_OPTIONS to the CC and its ilk
you will have issues.
May be you can reproduce it by
1. build first time ./oe-init-build-env /path/to/build1
2. Now set another builddir may be using ./oe-init-build-env /path/to/build2
3. Add a SSTATE_MIRROR pointing to sstate from first builddir add below to local.conf
SSTATE_MIRRORS ?= "\
file://.* file:///path/to/build1/sstate-cache/PATH”
4. bitbake <package>
5. bitbake -ccleansstate <package>
6. bitbake package
>
>> As this has been broken so many times, I want to discuss some possible fixes:
>> In the top level Makefile we have:
>> HOSTCC = cc
>> HOSTCFLAGS = ...
>> The problem is, you cannot properly override those variables, as they get used
>> a lot to do different things, e.g. in tools/Makefile we have (for cross tools
>> target) HOSTCC = $(CC) and for HOSTCFLAGS we have appends for configuration.
>> Thats why we have the current workaround with a squashed override. I see many
>> possible solutions and would like to hear your opinion:
>> 1. Make top level Makefile HOST assignments conditional "?="
>> - easy
>> - will probably not be accepted upstream
>
> Why ?
>
>> 2. add "override" to appends in sublevel Makefiles
>> - adds complexity/one level of override hierarchy
>> 3. Don't use appends for those variables (like in the kernel Makefile), overrides
>> in the recipe
>> - clean
>> - quite some rework in uboot
>
> Can you provide details ?
>
>> 4. Hack around in the recipe with class overrides and exports
>> - quickfix, no patch required
>> - fails easily in the future
>>
>> Any thoughts?
>> Stefan
>>
>
>
> --
> Best regards,
> Marek Vasut
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* [PATCH][krogoth] nss: fix compilation with glibc-2.24
From: Enrico Jorns @ 2016-10-28 6:06 UTC (permalink / raw)
To: openembedded-core
`readdir_r` is deprecated as of glibc-2.24 and leads to a compilation
error:
| In file included from sysrand.c:16:0:
| unix_rand.c: In function 'ReadOneFile':
| unix_rand.c:1090:6: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]
| error = readdir_r(fd, &entry_dir, &result);
| ^~~~~
| In file included from unix_rand.c:1032:0,
| from sysrand.c:16:
| /usr/include/dirent.h:183:12: note: declared here
| extern int readdir_r (DIR *__restrict __dirp,
| ^~~~~~~~~
| cc1: all warnings being treated as errors
The issue is reported in nss bug tracker
(https://bugzilla.mozilla.org/show_bug.cgi?id=1254334) and fixed in nss
mainline.
The fixing patch is extracted from the nss source code repository.
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
---
.../nss/nss/use-readdir-instead-of-readdir_r.patch | 95 ++++++++++++++++++++++
meta/recipes-support/nss/nss_3.21.bb | 1 +
2 files changed, 96 insertions(+)
create mode 100644 meta/recipes-support/nss/nss/use-readdir-instead-of-readdir_r.patch
diff --git a/meta/recipes-support/nss/nss/use-readdir-instead-of-readdir_r.patch b/meta/recipes-support/nss/nss/use-readdir-instead-of-readdir_r.patch
new file mode 100644
index 0000000..00f671f
--- /dev/null
+++ b/meta/recipes-support/nss/nss/use-readdir-instead-of-readdir_r.patch
@@ -0,0 +1,95 @@
+# HG changeset patch
+# User Martin Thomson <martin.thomson@gmail.com>
+# Date 1457600884 -39600
+# Thu Mar 10 20:08:04 2016 +1100
+# Node ID 7309fcbce2eceae1e4e3c687348e540905ae286a
+# Parent e7b6fca4f01427cafb4328f6e279af62290a2f34
+Bug 1254334 - Use readdir instead of readdir_r, r=emaldona, sr=rrelyea
+
+diff -r e7b6fca4f014 -r 7309fcbce2ec lib/freebl/unix_rand.c
+--- a/nss/lib/freebl/unix_rand.c Wed Apr 20 15:22:46 2016 +0200
++++ b/nss/lib/freebl/unix_rand.c Thu Mar 10 20:08:04 2016 +1100
+@@ -1054,26 +1054,16 @@
+ *
+ * return 1 if it's time to reset the fileToRead (no more files to read).
+ */
+-int ReadOneFile(int fileToRead)
++static int
++ReadOneFile(int fileToRead)
+ {
+ char *dir = "/etc";
+ DIR *fd = opendir(dir);
+ int resetCount = 0;
+-#ifdef SOLARIS
+- /* grumble, Solaris does not define struct dirent to be the full length */
+- typedef union {
+- unsigned char space[sizeof(struct dirent) + MAXNAMELEN];
+- struct dirent dir;
+- } dirent_hack;
+- dirent_hack entry, firstEntry;
+-
+-#define entry_dir entry.dir
+-#else
+- struct dirent entry, firstEntry;
+-#define entry_dir entry
+-#endif
+-
+- int i, error = -1;
++ struct dirent *entry;
++ char firstName[NAME_MAX + 1];
++ const char *name = NULL;
++ int i;
+
+ if (fd == NULL) {
+ dir = PR_GetEnvSecure("HOME");
+@@ -1085,33 +1075,34 @@
+ return 1;
+ }
+
++ firstName[0] = '\0';
+ for (i=0; i <= fileToRead; i++) {
+- struct dirent *result = NULL;
+ do {
+- error = readdir_r(fd, &entry_dir, &result);
+- } while (error == 0 && result != NULL &&
+- !ReadFileOK(dir,&result->d_name[0]));
+- if (error != 0 || result == NULL) {
++ /* readdir() isn't guaranteed to be thread safe on every platform;
++ * this code assumes the same directory isn't read concurrently.
++ * This usage is confirmed safe on Linux, see bug 1254334. */
++ entry = readdir(fd);
++ } while (entry != NULL && !ReadFileOK(dir, &entry->d_name[0]));
++ if (entry == NULL) {
+ resetCount = 1; /* read to the end, start again at the beginning */
+- if (i != 0) {
++ if (firstName[0]) {
+ /* ran out of entries in the directory, use the first one */
+- entry = firstEntry;
+- error = 0;
+- break;
++ name = firstName;
+ }
+- /* if i== 0, there were no readable entries in the directory */
+ break;
+ }
+- if (i==0) {
+- /* save the first entry in case we run out of entries */
+- firstEntry = entry;
++ name = entry->d_name;
++ if (i == 0) {
++ /* copy the name of the first in case we run out of entries */
++ PORT_Assert(PORT_Strlen(name) <= NAME_MAX);
++ PORT_Strncpy(firstName, name, NAME_MAX);
++ firstName[NAME_MAX] = '\0';
+ }
+ }
+
+- if (error == 0) {
++ if (name) {
+ char filename[PATH_MAX];
+- int count = snprintf(filename, sizeof filename,
+- "%s/%s",dir, &entry_dir.d_name[0]);
++ int count = snprintf(filename, sizeof(filename), "%s/%s",dir, name);
+ if (count >= 1) {
+ ReadSingleFile(filename);
+ }
diff --git a/meta/recipes-support/nss/nss_3.21.bb b/meta/recipes-support/nss/nss_3.21.bb
index 05d81c2..39b0994 100644
--- a/meta/recipes-support/nss/nss_3.21.bb
+++ b/meta/recipes-support/nss/nss_3.21.bb
@@ -21,6 +21,7 @@ SRC_URI = "\
file://nss-fix-incorrect-shebang-of-perl.patch \
file://nss-fix-nsinstall-build.patch \
file://0001-Fix-build-failure-on-opensuse-13.1.patch \
+ file://use-readdir-instead-of-readdir_r.patch \
file://nss-gcc6-fix.patch \
file://nss.pc.in \
file://signlibs.sh \
--
2.9.3
^ permalink raw reply related
* [PATCH][krogoth] pseudo: backport 'Work around issues with glibc 2.24'
From: Enrico Jorns @ 2016-10-28 6:09 UTC (permalink / raw)
To: openembedded-core
This patch is required for krogoth, too in order to make it properly
work with glibc 2.24.
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Below the message of the original commit:
There are issues with a change made to RTLD_NEXT behaviour in glibc 2.24
and that change was also backported to older glibc versions in some distros
like Fedora 23. This adds a workaround whilst the pseudo maintainer fixes
various issues properly.
(From OE-Core rev: 21c38a091c4a1917f62a942c4751b0fd11dce340)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta-jupiter | 2 +-
.../pseudo/pseudo-glibc-rtld-next-workaround.patch | 85 ++++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.7.5.bb | 1 +
3 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
diff --git a/meta-jupiter b/meta-jupiter
index a1299a3..5a66c62 160000
--- a/meta-jupiter
+++ b/meta-jupiter
@@ -1 +1 @@
-Subproject commit a1299a3e711c93ed8a7eb652bdbacd83669263c6
+Subproject commit 5a66c628800824585208d0130ee6b731c7e95edd
diff --git a/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch b/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
new file mode 100644
index 0000000..6710734
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
@@ -0,0 +1,85 @@
+We started seeing:
+
+No real function for mknod: /home/paul/poky_sdk/tmp/sysroots/x86_64-
+linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod
+No real function for mknodat: /home/paul/poky_sdk/tmp/sysroots/x86_64-
+linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknodat
+
+In glibc 2.24 they've merged:
+
+https://sourceware.org/git/?p=glibc.git;a=commit;h=7d45c163d00c88d5875a112343c4ea3e61349e6b
+related to bugzilla entry:
+https://sourceware.org/bugzilla/show_bug.cgi?id=19509
+
+which means that the behaviour of RTLD_NEXT is slightly different.
+As far as I can tell, mknod has not been present in glibc for a while.
+To quote stat.h:
+
+/* To allow the `struct stat' structure and the file type `mode_t'
+ bits to vary without changing shared library major version number,
+ the `stat' family of functions and `mknod' are in fact inline
+ wrappers around calls to `xstat', `fxstat', `lxstat', and `xmknod',
+ which all take a leading version-number argument designating the
+ data structure and bits used. <bits/stat.h> defines _STAT_VER with
+ the version number corresponding to `struct stat' as defined in
+ that file; and _MKNOD_VER with the version number corresponding to
+ the S_IF* macros defined therein. It is arranged that when not
+ inlined these function are always statically linked; that way a
+ dynamically-linked executable always encodes the version number
+ corresponding to the data structures it uses, so the `x' functions
+ in the shared library can adapt without needing to recompile all
+ callers. */
+
+so I suspect mknod has not existed for a while, if ever and what we
+were finding, who knows. Everying in the system links against _xmknod
+which we have a separate wrapper for.
+
+Anyhow, ignoring that problem which hasn't caused a issue in the past,
+the RTLD_NEXT change causes messages to be printed to stdout which causes
+carnage if for example the packaging code is expecting a list of packages:
+
+WARNING: core-image-minimal-1.0-r0 do_rootfs: No not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: real not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: function not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: for not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: mknod: not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+[etc]
+
+This bug will affect:
+* any distro using glibc 2.24
+* any system using a uninative tarball for glibc 2.24
+* any system which took a backport for the fix which was merged into
+ the 2.23 branch for a while before it was reverted (Fedora 23 had this)
+
+The easiest thing to do is to ignore the problem and disable the diag
+message which masks the problem with no ill effects.
+
+As Peter notes, there are a few issues here:
+
+* the fact there is no mknod symbol
+* the fact an error here isn't fatal
+* the #ifdef/#else looks suspect
+* handle RTLD_NEXT chaining properly (need more libs?)
+
+which he'll work on upstream and hopefully have fixed in a new version.
+
+Upstream-Status: Submitted [Peter is aware of the issue]
+
+RP 2016/5/18
+
+Index: pseudo-1.7.5/pseudo_wrappers.c
+===================================================================
+--- pseudo-1.7.5.orig/pseudo_wrappers.c
++++ pseudo-1.7.5/pseudo_wrappers.c
+@@ -146,9 +146,9 @@ pseudo_init_one_wrapper(pseudo_function
+ return;
+ }
+ #else
+- if (e != NULL) {
++ /*if (e != NULL) {
+ pseudo_diag("No real function for %s: %s\n", func->name, e);
+- }
++ }*/
+ #endif
+ }
+ }
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb b/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
index d90e644..38e6f4d 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
@@ -7,6 +7,7 @@ SRC_URI = " \
file://fallback-group \
file://moreretries.patch \
file://handle-remove-xattr.patch \
+ file://pseudo-glibc-rtld-next-workaround.patch \
"
SRC_URI[md5sum] = "c10209938f03128d0c193f041ff3596d"
--
2.9.3
^ permalink raw reply related
* [PATCH v2][krogoth] pseudo: backport 'Work around issues with glibc 2.24'
From: Enrico Jorns @ 2016-10-28 6:36 UTC (permalink / raw)
To: openembedded-core; +Cc: Enrico Jorns
In-Reply-To: <20161028060902.1133-1-ejo@pengutronix.de>
This patch is required for krogoth, too in order to make it properly
work with glibc 2.24.
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Below the message of the original commit:
There are issues with a change made to RTLD_NEXT behaviour in glibc 2.24
and that change was also backported to older glibc versions in some distros
like Fedora 23. This adds a workaround whilst the pseudo maintainer fixes
various issues properly.
(From OE-Core rev: 21c38a091c4a1917f62a942c4751b0fd11dce340)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
Cleaned-up version of the former patch.
.../pseudo/pseudo-glibc-rtld-next-workaround.patch | 85 ++++++++++++++++++++++
meta/recipes-devtools/pseudo/pseudo_1.7.5.bb | 1 +
2 files changed, 86 insertions(+)
create mode 100644 meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
diff --git a/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch b/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
new file mode 100644
index 0000000..6710734
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/pseudo/pseudo-glibc-rtld-next-workaround.patch
@@ -0,0 +1,85 @@
+We started seeing:
+
+No real function for mknod: /home/paul/poky_sdk/tmp/sysroots/x86_64-
+linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknod
+No real function for mknodat: /home/paul/poky_sdk/tmp/sysroots/x86_64-
+linux/usr/bin/../lib/pseudo/lib64/libpseudo.so: undefined symbol: mknodat
+
+In glibc 2.24 they've merged:
+
+https://sourceware.org/git/?p=glibc.git;a=commit;h=7d45c163d00c88d5875a112343c4ea3e61349e6b
+related to bugzilla entry:
+https://sourceware.org/bugzilla/show_bug.cgi?id=19509
+
+which means that the behaviour of RTLD_NEXT is slightly different.
+As far as I can tell, mknod has not been present in glibc for a while.
+To quote stat.h:
+
+/* To allow the `struct stat' structure and the file type `mode_t'
+ bits to vary without changing shared library major version number,
+ the `stat' family of functions and `mknod' are in fact inline
+ wrappers around calls to `xstat', `fxstat', `lxstat', and `xmknod',
+ which all take a leading version-number argument designating the
+ data structure and bits used. <bits/stat.h> defines _STAT_VER with
+ the version number corresponding to `struct stat' as defined in
+ that file; and _MKNOD_VER with the version number corresponding to
+ the S_IF* macros defined therein. It is arranged that when not
+ inlined these function are always statically linked; that way a
+ dynamically-linked executable always encodes the version number
+ corresponding to the data structures it uses, so the `x' functions
+ in the shared library can adapt without needing to recompile all
+ callers. */
+
+so I suspect mknod has not existed for a while, if ever and what we
+were finding, who knows. Everying in the system links against _xmknod
+which we have a separate wrapper for.
+
+Anyhow, ignoring that problem which hasn't caused a issue in the past,
+the RTLD_NEXT change causes messages to be printed to stdout which causes
+carnage if for example the packaging code is expecting a list of packages:
+
+WARNING: core-image-minimal-1.0-r0 do_rootfs: No not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: real not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: function not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: for not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+WARNING: core-image-minimal-1.0-r0 do_rootfs: mknod: not found in the base feeds (qemux86_64 core2-64 x86_64 noarch any all).
+[etc]
+
+This bug will affect:
+* any distro using glibc 2.24
+* any system using a uninative tarball for glibc 2.24
+* any system which took a backport for the fix which was merged into
+ the 2.23 branch for a while before it was reverted (Fedora 23 had this)
+
+The easiest thing to do is to ignore the problem and disable the diag
+message which masks the problem with no ill effects.
+
+As Peter notes, there are a few issues here:
+
+* the fact there is no mknod symbol
+* the fact an error here isn't fatal
+* the #ifdef/#else looks suspect
+* handle RTLD_NEXT chaining properly (need more libs?)
+
+which he'll work on upstream and hopefully have fixed in a new version.
+
+Upstream-Status: Submitted [Peter is aware of the issue]
+
+RP 2016/5/18
+
+Index: pseudo-1.7.5/pseudo_wrappers.c
+===================================================================
+--- pseudo-1.7.5.orig/pseudo_wrappers.c
++++ pseudo-1.7.5/pseudo_wrappers.c
+@@ -146,9 +146,9 @@ pseudo_init_one_wrapper(pseudo_function
+ return;
+ }
+ #else
+- if (e != NULL) {
++ /*if (e != NULL) {
+ pseudo_diag("No real function for %s: %s\n", func->name, e);
+- }
++ }*/
+ #endif
+ }
+ }
diff --git a/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb b/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
index d90e644..38e6f4d 100644
--- a/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_1.7.5.bb
@@ -7,6 +7,7 @@ SRC_URI = " \
file://fallback-group \
file://moreretries.patch \
file://handle-remove-xattr.patch \
+ file://pseudo-glibc-rtld-next-workaround.patch \
"
SRC_URI[md5sum] = "c10209938f03128d0c193f041ff3596d"
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox