[OE-core] [PATCH] ltp: Fix nm01 faliure
From: He Zhe
Backport a patch from upstream to fix the following runtime failure.
The latest nm v2.33.1 outputs symbols addresses without prefix zeros
for "nm -f posix", which causes the following error.
nm01 5 TFAIL: Got wrong format with -f bsd
(From OE-Core rev: 59cb0dd9f8e65b2d398fcaf4d163cbc8e1d0ae45)
Signed-off-by: He Zhe
---
...ix-zeros-of-the-addresses-output-by-.patch | 41 +++
meta/recipes-extended/ltp/ltp_20190930.bb | 1 +
2 files changed, 42 insertions(+)
create mode 100644
meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
diff --git
a/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
b/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
new file mode 100644
index 00..a98a104384
--- /dev/null
+++
b/meta/recipes-extended/ltp/ltp/0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch
@@ -0,0 +1,41 @@
+From 59cb0dd9f8e65b2d398fcaf4d163cbc8e1d0ae45 Mon Sep 17 00:00:00 2001
+From: He Zhe
+Date: Tue, 31 Dec 2019 15:02:48 +0800
+Subject: [PATCH] nm01: Remove prefix zeros of the addresses output by nm
+ before comparing
+
+The latest nm v2.33.1 outputs symbols addresses without prefix zeros
+for "nm -f posix", which causes the following error.
+nm01 5 TFAIL: Got wrong format with -f bsd
+
+Let's remove the prefix zeros before comparing.
+
+Signed-off-by: He Zhe
+Reviewed-by: Li Wang
+Reviewed-by: Petr Vorel
+Tested-by: Petr Vorel
+---
+ testcases/commands/nm/nm01.sh | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/testcases/commands/nm/nm01.sh b/testcases/commands/nm/nm01.sh
+index 30c41bd..fd9d3d9 100755
+--- a/testcases/commands/nm/nm01.sh
b/testcases/commands/nm/nm01.sh
+@@ -84,8 +84,11 @@ test5()
+ EXPECT_PASS $NM -f bsd $TST_DATAROOT/f1 \> nm_bsd.out
+ EXPECT_PASS $NM -f posix $TST_DATAROOT/f1 \> nm_posix.out
+
+- ROD awk '{print $3 $2 $1}' nm_bsd.out \> nm1.out
+- ROD awk '{print $1 $2 $3}' nm_posix.out \> nm2.out
++ ROD awk '{print gensub(/\y(0+)([0-9a-fA-F]+)\y/, "\\2", "g")}'
nm_bsd.out \> trimmed_nm_bsd.out
++ ROD awk '{print gensub(/\y(0+)([0-9a-fA-F]+)\y/, "\\2", "g")}'
nm_posix.out \> trimmed_nm_posix.out
++
++ ROD awk '{print $3 $2 $1}' trimmed_nm_bsd.out \> nm1.out
++ ROD awk '{print $1 $2 $3}' trimmed_nm_posix.out \> nm2.out
+
+ if diff nm1.out nm2.out > /dev/null; then
+ tst_res TPASS "Got BSD format with -f bsd"
+--
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20190930.bb
b/meta/recipes-extended/ltp/ltp_20190930.bb
index e56bb575d2..2853b1c819 100644
--- a/meta/recipes-extended/ltp/ltp_20190930.bb
+++ b/meta/recipes-extended/ltp/ltp_20190930.bb
@@ -41,6 +41,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0001-mkswap01.sh-Add-udevadm-trigger-before-swap-verifica.patch \
file://0001-testcases-fix-an-absent-format-string-issue.patch \
file://0001-Add-more-musl-exclusions.patch \
+
file://0001-nm01-Remove-prefix-zeros-of-the-addresses-output-by-.patch \
"
S = "${WORKDIR}/git"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)
On 01/19/20 13:32, Patchwork wrote: == Series Details == Series: Open file with O_CLOEXEC to avoid fd leak (rev3) Revision: 3 URL : https://patchwork.openembedded.org/series/22123/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 9d7a521971) Have already rebased on the master branch of http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/, why still issue out the above issue? Any hint? Thanks, If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev3)
== Series Details == Series: Open file with O_CLOEXEC to avoid fd leak (rev3) Revision: 3 URL : https://patchwork.openembedded.org/series/22123/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 9d7a521971) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak
From: Pavel Modilaynen
Use close-on-exec (O_CLOEXEC) flag when open log file to
make sure its file descriptor is not leaked to parent
process on fork/exec.
Signed-off-by: Mingli Yu
---
pseudo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pseudo_util.c b/pseudo_util.c
index c867ed6..0ec527b 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -1594,7 +1594,7 @@ pseudo_logfile(char *filename, char *defname, int
prefer_fd) {
}
free(filename);
}
- fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644);
+ fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT | O_CLOEXEC, 0644);
if (fd == -1) {
pseudo_diag("help: can't open log file %s: %s\n", pseudo_path,
strerror(errno));
} else {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak (rev2)
== Series Details == Series: Open file with O_CLOEXEC to avoid fd leak (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/22123/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 9d7a521971) * Patch[v2] Open file with O_CLOEXEC to avoid fd leak Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] Open file with O_CLOEXEC to avoid fd leak
From: Pavel Modilaynen
Use close-on-exec (O_CLOEXEC) flag when open log file to
make sure its file descriptor is not leaked to parent
process on fork/exec.
Signed-off-by: Mingli Yu
---
pseudo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pseudo_util.c b/pseudo_util.c
index c867ed6..0ec527b 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -1594,7 +1594,7 @@ pseudo_logfile(char *filename, char *defname, int
prefer_fd) {
}
free(filename);
}
- fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644);
+ fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT | O_CLOEXEC, 0644);
if (fd == -1) {
pseudo_diag("help: can't open log file %s: %s\n", pseudo_path,
strerror(errno));
} else {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Open file with O_CLOEXEC to avoid fd leak
== Series Details == Series: Open file with O_CLOEXEC to avoid fd leak Revision: 1 URL : https://patchwork.openembedded.org/series/22123/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 9d7a521971) * PatchOpen file with O_CLOEXEC to avoid fd leak Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " * PatchOpen file with O_CLOEXEC to avoid fd leak Issue Patch is missing Signed-off-by [test_signed_off_by_presence] Suggested fixSign off the patch (either manually or with "git commit --amend -s") If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Open file with O_CLOEXEC to avoid fd leak
From: Pavel Modilaynen
Use close-on-exec (O_CLOEXEC) flag when open log file to
make sure its file descriptor is not leaked to parent
process on fork/exec.
---
pseudo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pseudo_util.c b/pseudo_util.c
index c867ed6..0ec527b 100644
--- a/pseudo_util.c
+++ b/pseudo_util.c
@@ -1594,7 +1594,7 @@ pseudo_logfile(char *filename, char *defname, int
prefer_fd) {
}
free(filename);
}
- fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644);
+ fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT | O_CLOEXEC, 0644);
if (fd == -1) {
pseudo_diag("help: can't open log file %s: %s\n", pseudo_path,
strerror(errno));
} else {
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] newlib: Enable building libstdc++ for newlib based toolchains
Some baremetal applications might require support from libstdc++
On newlib based toolchains, libstdc++ can be built as a static
library that applications can then link against it.
Pass libsdtc++-(static)dev to LIBC_DEPENDENCIES allowing the
library to be present for cross compilation as well as on
sdk builds.
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
meta/conf/distro/include/tclibc-newlib.inc | 7 +++
meta/recipes-devtools/gcc/gcc-runtime.inc | 6 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/meta/conf/distro/include/tclibc-newlib.inc
b/meta/conf/distro/include/tclibc-newlib.inc
index 896c0b1..8338003 100644
--- a/meta/conf/distro/include/tclibc-newlib.inc
+++ b/meta/conf/distro/include/tclibc-newlib.inc
@@ -25,12 +25,11 @@ LIBC_DEPENDENCIES = "\
libgloss-dbg \
libgcc-dev \
libgcc-dbg \
+libstdc++-dev \
+libstdc++-staticdev \
"
-# compilerlibs defaults to gcc-runtime, but we get runtime from libgloss
-# we set ASSUME_PROVIDED because we cant set PREFERRED_PROVIDER
-# for compilerlibs since its overridden by tcmode-default
-ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}compilerlibs virtual/crypt"
+ASSUME_PROVIDED += "virtual/crypt"
# Its useful to be able to extend newlib, but we dont provide a native variant
of libgloss
NEWLIB_EXTENDED ?= "libgloss libgcc"
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index d3f8ae8..b2c5d43 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -16,10 +16,14 @@ EXTRA_OECONF_PATHS = "\
EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
+EXTRA_OECONF_append_libc-newlib = " --with-newlib"
# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
+# Newlib does not support symbol versioning on libsdtcc++
+SYMVERS_CONF_libc-newlib = ""
+
# Building with thumb enabled on armv6t fails
ARM_INSTRUCTION_SET_armv6 = "arm"
@@ -36,6 +40,8 @@ RUNTIMELIBSSP_mingw32 ?= "libssp"
RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
${RUNTIMELIBITM} \
${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath',
'', d)} \
"
+# Only build libstdc++ for newlib
+RUNTIMETARGET_libc-newlib = "libstdc++-v3"
# libiberty
# libmudflap
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc-configure: Enable the use of different symbol versioning
While the gnu style for symbol versioning is the most usual,
--enable-symvers[=style] can be provided several values,
gnu, gnu-versioned-namespace, darwin, darwin-export, and sun,
depending on users needs.
Introduce the SYMVERS_CONF variable to allow the user to
configure the symbol versioning in shared libraries.
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
meta/recipes-devtools/gcc/gcc-configure-common.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 24ba8ce..bb4f692 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -17,6 +17,8 @@ GCCTHREADS ?= "posix"
GCCPIE ??= ""
+SYMVERS_CONF ?= "--enable-symvers=gnu"
+
EXTRA_OECONF = "\
${@['--enable-clocale=generic', ''][d.getVar('USE_NLS') != 'no']} \
--with-gnu-ld \
@@ -27,7 +29,7 @@ EXTRA_OECONF = "\
${GCCPIE} \
--enable-c99 \
--enable-long-long \
---enable-symvers=gnu \
+${SYMVERS_CONF} \
--enable-libstdcxx-pch \
--program-prefix=${TARGET_PREFIX} \
--without-local-prefix \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dnf: upgrade 4.2.2 -> 4.2.18
Signed-off-by: Wang Mingyu
---
meta/recipes-devtools/dnf/{dnf_4.2.2.bb => dnf_4.2.18.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/dnf/{dnf_4.2.2.bb => dnf_4.2.18.bb} (98%)
diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
b/meta/recipes-devtools/dnf/dnf_4.2.18.bb
similarity index 98%
rename from meta/recipes-devtools/dnf/dnf_4.2.2.bb
rename to meta/recipes-devtools/dnf/dnf_4.2.18.bb
index f38167f1ad..fd4380723e 100644
--- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
+++ b/meta/recipes-devtools/dnf/dnf_4.2.18.bb
@@ -15,7 +15,7 @@ SRC_URI = "git://github.com/rpm-software-management/dnf.git \
file://0030-Run-python-scripts-using-env.patch \
"
-SRCREV = "9947306a55271b8b7c9e2b6e3b7d582885b6045d"
+SRCREV = "ff1972b52007ccb701c43e3c2bf2bd2e40ac32ac"
UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
S = "${WORKDIR}/git"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] newlib: Enable building libstdc++ for newlib based toolchains
On Sat, 18 Jan 2020 at 15:25, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Sat, 2020-01-18 at 13:22 -0800, Alejandro Enedino Hernandez
> Samaniego wrote:
> > Some baremetal applications might require support from libstdc++.
> >
> > On newlib based toolchains, libstdc++ can be built as a static
> > library that applications can then link against it.
> >
> > Pass libsdtc++-(static)dev to LIBC_DEPENDENCIES allowing the
> > library to be present for cross compilation as well as on
> > sdk builds.
> >
> > This also requires to modify the gcc-runtime recipe to
> > explictly build only libsdtc++ correctly.
> >
> > Signed-off-by: Alejandro Enedino Hernandez Samaniego <
> > alejan...@enedino.org>
> > ---
> > meta/conf/distro/include/tclibc-newlib.inc | 7 +++
> > meta/recipes-devtools/gcc/gcc-runtime.inc | 6 ++
> > 2 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/tclibc-newlib.inc
> > b/meta/conf/distro/include/tclibc-newlib.inc
> > index 896c0b1..8338003 100644
> > --- a/meta/conf/distro/include/tclibc-newlib.inc
> > +++ b/meta/conf/distro/include/tclibc-newlib.inc
> > @@ -25,12 +25,11 @@ LIBC_DEPENDENCIES = "\
> > libgloss-dbg \
> > libgcc-dev \
> > libgcc-dbg \
> > +libstdc++-dev \
> > +libstdc++-staticdev \
> > "
> >
> > -# compilerlibs defaults to gcc-runtime, but we get runtime from
> > libgloss
> > -# we set ASSUME_PROVIDED because we cant set PREFERRED_PROVIDER
> > -# for compilerlibs since its overridden by tcmode-default
> > -ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}compilerlibs
> > virtual/crypt"
> > +ASSUME_PROVIDED += "virtual/crypt"
> >
> > # Its useful to be able to extend newlib, but we dont provide a
> > native variant of libgloss
> > NEWLIB_EXTENDED ?= "libgloss libgcc"
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > index d3f8ae8..f035fbd 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -17,6 +17,9 @@ EXTRA_OECONF_PATHS = "\
> > EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
> > EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
> >
> > +EXTRA_OECONF_remove_libc-newlib = "--enable-symvers=gnu"
> > +EXTRA_OECONF_append_libc-newlib = " --with-newlib"
> > +
>
> I really don't like using remove in core. Can we restructure this so
> that symvers is set something like:
>
> SYMVERS_CONF = " --enable-clocale=gnu"
> SYMVERS_CONF_libc-newlib = ""
> EXTRA_OECONF_append += "${SYMVERS_CONF}"
>
> ?
>
Hey Richard,
Absolutely agree, I will send a v2 with these changes.
Alejandro
>
> > # Disable ifuncs for libatomic on arm conflicts -march/-mcpu
> > EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
> >
> > @@ -33,6 +36,9 @@ RUNTIMELIBITM_riscv64 = ""
> > RUNTIMELIBSSP ?= ""
> > RUNTIMELIBSSP_mingw32 ?= "libssp"
> >
> > +# Only build libstdc++ for newlib
> > +RUNTIMETARGET_libc-newlib = "libstdc++-v3"
> > +
> > RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
> > ${RUNTIMELIBITM} \
> > ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'],
> > 'libquadmath', '', d)} \
> > "
>
> Convention is top put the overridden version under the original.
>
Will change this as well
>
> Cheers,
>
> Richard
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] glibc and LDFLAGS
On Sat, 2020-01-18 at 22:25 +, Rasmus Villemoes wrote: > I've added a custom setting to TARGET_LDFLAGS, but then I noticed > that > the glibc build ignored that. The glibc do_compile did > > LDFLAGS = "" > > for a very long time, with the explanation that "# -Wl,-rpath-link > /lib in LDFLAGS can cause breakage if another glibc is in > staging". Is that actually still relevant with per-recipe staging? It is obsolete now, correct. > If that is indeed moot, can we do > > CPPFLAGS="" oe_runconf > } > > +LDFLAGS += "-fuse-ld=bfd" Its worth a try... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] newlib: Enable building libstdc++ for newlib based toolchains
On Sat, 2020-01-18 at 13:22 -0800, Alejandro Enedino Hernandez
Samaniego wrote:
> Some baremetal applications might require support from libstdc++.
>
> On newlib based toolchains, libstdc++ can be built as a static
> library that applications can then link against it.
>
> Pass libsdtc++-(static)dev to LIBC_DEPENDENCIES allowing the
> library to be present for cross compilation as well as on
> sdk builds.
>
> This also requires to modify the gcc-runtime recipe to
> explictly build only libsdtc++ correctly.
>
> Signed-off-by: Alejandro Enedino Hernandez Samaniego <
> alejan...@enedino.org>
> ---
> meta/conf/distro/include/tclibc-newlib.inc | 7 +++
> meta/recipes-devtools/gcc/gcc-runtime.inc | 6 ++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/meta/conf/distro/include/tclibc-newlib.inc
> b/meta/conf/distro/include/tclibc-newlib.inc
> index 896c0b1..8338003 100644
> --- a/meta/conf/distro/include/tclibc-newlib.inc
> +++ b/meta/conf/distro/include/tclibc-newlib.inc
> @@ -25,12 +25,11 @@ LIBC_DEPENDENCIES = "\
> libgloss-dbg \
> libgcc-dev \
> libgcc-dbg \
> +libstdc++-dev \
> +libstdc++-staticdev \
> "
>
> -# compilerlibs defaults to gcc-runtime, but we get runtime from
> libgloss
> -# we set ASSUME_PROVIDED because we cant set PREFERRED_PROVIDER
> -# for compilerlibs since its overridden by tcmode-default
> -ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}compilerlibs
> virtual/crypt"
> +ASSUME_PROVIDED += "virtual/crypt"
>
> # Its useful to be able to extend newlib, but we dont provide a
> native variant of libgloss
> NEWLIB_EXTENDED ?= "libgloss libgcc"
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index d3f8ae8..f035fbd 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -17,6 +17,9 @@ EXTRA_OECONF_PATHS = "\
> EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
> EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
>
> +EXTRA_OECONF_remove_libc-newlib = "--enable-symvers=gnu"
> +EXTRA_OECONF_append_libc-newlib = " --with-newlib"
> +
I really don't like using remove in core. Can we restructure this so
that symvers is set something like:
SYMVERS_CONF = " --enable-clocale=gnu"
SYMVERS_CONF_libc-newlib = ""
EXTRA_OECONF_append += "${SYMVERS_CONF}"
?
> # Disable ifuncs for libatomic on arm conflicts -march/-mcpu
> EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
>
> @@ -33,6 +36,9 @@ RUNTIMELIBITM_riscv64 = ""
> RUNTIMELIBSSP ?= ""
> RUNTIMELIBSSP_mingw32 ?= "libssp"
>
> +# Only build libstdc++ for newlib
> +RUNTIMETARGET_libc-newlib = "libstdc++-v3"
> +
> RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
> ${RUNTIMELIBITM} \
> ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'],
> 'libquadmath', '', d)} \
> "
Convention is top put the overridden version under the original.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] logrotate.py: improve oeqa test implementation
On Thu, 2020-01-16 at 15:19 -0500, Trevor Gamblin wrote: > From: Trevor Gamblin > > See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632 > > Autobuilder tests occasionally fail, reporting that a new logfile > could not be created. While this failure did occur multiple times, it > could not be manually reproduced. However, there are issues with the > implementation of the logrotate.py script that can be fixed. These > changes will help make the failures clearer, should they continue to > occur. > > Previously, the test_2_logrotate test would, after running the > logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count > the number of files in the rotation directory and determine if the > rotation was successful. The test to see if there are at least three > files is problematic, because depending on the version of ls used, it > may report the target value of 3 even when there are only hidden > files > in the directory, potentially reporting a pass for the test when it > should actually fail. An example with coreutils: > > root@qemux86-64:~# ls -al emptydir/ > total 2 > drwxr-xr-x 2 root root 1024 Jan 14 19:50 . > drwx-- 3 root root 1024 Jan 14 19:50 .. > root@qemux86-64:~# > > Where "total" is the number of blocks used. Compare with busybox ls: > > root@qemux86-64:~# ls -al emptydir/ > drwxr-xr-x2 root root 1024 Jan 14 19:54 . > drwx--3 root root 1024 Jan 14 19:54 .. > root@qemux86-64:~# > > Instead of using ls to verify that a certain number of files exists > in $HOME/logrotate_dir, the tests have been changed to rotate two > specific logs: the log for wtmp and a new logrotate_testfile created > during the second test. Both tests check that the logs are correctly > rotated into $HOME/logrotate_dir by using find and grep on the > expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we > check to see that wtmp.1 is present in $HOME/logrotate_dir). In > addition, should the test fail, the directory listing is included in > the log to aid debugging. > > Finally, note that while the autobuilder failures that this patch > addresses were only seen during core-image-full-cmdline tests, these > changes were successfully tested on core-image-minimal and > core-image-sato with the manual addition of logrotate and openssh- > sshd > to the images. > > Signed-off-by: Trevor Gamblin Thanks for this, I haven't looked in detail but test builds came back with: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1464 Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libfm: Add mime and mime-xdg classes
On Sat, Jan 18, 2020 at 6:48 PM Richard Purdie
wrote:
>
> libfm installs mime types we want in our mime-database and it also uses
> desktop files
> containing MimeType.
>
> Signed-off-by: Richard Purdie
> ---
> meta/recipes-support/libfm/libfm_1.3.1.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/libfm/libfm_1.3.1.bb
> b/meta/recipes-support/libfm/libfm_1.3.1.bb
> index 918fe3ece70..63ae7874b95 100644
> --- a/meta/recipes-support/libfm/libfm_1.3.1.bb
> +++ b/meta/recipes-support/libfm/libfm_1.3.1.bb
> @@ -19,7 +19,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/pcmanfm/libfm-${PV}.tar.xz
> \
> SRC_URI[md5sum] = "c15ecd2c9317e2c385cd3f046d0b61ba"
> SRC_URI[sha256sum] =
> "96b1244bde41ca0eef0332cfb5c67bb16725dfd102128f3e6f74fadc13a1cfe4"
>
> -inherit autotools pkgconfig gtk-doc gettext features_check
> +inherit autotools pkgconfig gtk-doc gettext features_check mime mime-xdg
> ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
>
> EXTRA_OECONF = "--with-gtk=3"
> --
> 2.20.1
Thanks
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] glibc and LDFLAGS
I've added a custom setting to TARGET_LDFLAGS, but then I noticed that
the glibc build ignored that. The glibc do_compile did
LDFLAGS = ""
for a very long time, with the explanation that "# -Wl,-rpath-link
/lib in LDFLAGS can cause breakage if another glibc is in
staging". Is that actually still relevant with per-recipe staging?
If that is indeed moot, can we do
CPPFLAGS="" oe_runconf
}
+LDFLAGS += "-fuse-ld=bfd"
do_compile () {
- # -Wl,-rpath-link /lib in LDFLAGS can cause breakage if
another glibc is in staging
- LDFLAGS="-fuse-ld=bfd"
base_do_compile
echo "Adjust ldd script"
if [ -n "${RTLDLIST}" ]
?
And if not, at least move the LDFLAGS definition out to recipe level so
"bitbake -e" will show the value actually in effect? (And that would
also allow a .bbappend to tweak glibc's LDFLAGS with my custom setting,
though it's annoying to have to maintain that, so the best is if glibc
can just be built with the global LDFLAGS setting).
Rasmus
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [AUH] Upgrade status: 2020-01-18
Recipe upgrade statistics: * Failed (devtool error): 19 sysklogd, 2.1, Chen Qi ifupdown, 0.8.35, Anuj Mittal rpm, 4.15.1, Mark Hatle rt-tests, 1.6, Alexander Kanavin e2fsprogs, 1.45.5, Robert Yang acl, 2.2.53, Chen Qi atk, 2.34.1, Anuj Mittal python3, 3.8.1, Oleksandr Kravchuk libva, 20130827, Anuj Mittal ltp, 20190930, Yi Zhao qemu, 4.2.0, Richard Purdie elfutils, 0.178, Hongxu Jia systemd-boot, 244.1, Chen Qi build-compare, 2019.08.14-new-commits-available, Paul Eggleton libinput, 1.15.0, Ross Burton attr, 2.4.48, Chen Qi apt, 1.9.5, Aníbal Limón libtirpc, 1.2.5, Anuj Mittal weston, 7.0.92, Denys Dmytriyenko * Failed(do_compile): 31 cmake, 3.16.2, Pascal Bach gstreamer1.0-plugins-ugly, 1.16.2, Anuj Mittal ruby, 2.7.0, Ross Burton go, 1.13.6, Khem Raj go-runtime, 1.13.6, Khem Raj gstreamer1.0-plugins-good, 1.16.2, Anuj Mittal mesa, 19.3.2, Otavio Salvador vulkan-tools, 1.1.130.0, Anuj Mittal python3-numpy, 1.18.1, Oleksandr Kravchuk at-spi2-atk, 2.34.1, Anuj Mittal vulkan-demos, git-new-commits-available, Ross Burton gstreamer1.0-plugins-base, 1.16.2, Anuj Mittal gstreamer1.0-omx, 1.16.2, Anuj Mittal git, 2.25.0, Robert Yang python3-scons, 3.1.2, Tim Orling gst-validate, 1.16.2, Anuj Mittal gstreamer1.0-libav, 1.16.2, Anuj Mittal netbase, 6.0, Armin Kuster bind, 9.11.14, Armin Kuster meson, 0.53.0, Alexander Kanavin vulkan-loader, 1.2.131.0, Anuj Mittal python-setuptools, 45.0.0, Oleksandr Kravchuk gstreamer1.0-rtsp-server, 1.16.2, Anuj Mittal u-boot, 2020.01, Marek Vasut acpica, 20200110, Ross Burton libdnf, 0.43.1, Alexander Kanavin libsecret, 0.20.0, Alexander Kanavin vulkan-headers, 1.1.130.0, Anuj Mittal nss, 3.49.1, Armin Kuster gstreamer1.0-vaapi, 1.16.2, Anuj Mittal gstreamer1.0-plugins-bad, 1.16.2, Anuj Mittal * Succeeded: 53 iproute2, 5.4.0, Changhyeok Bae btrfs-tools, 5.4.1, Alexander Kanavin bison, 3.5, Chen Qi gnupg, 2.2.19, Hongxu Jia puzzles, 0.0-new-commits-available, Anuj Mittal socat, 1.7.3.4, Hongxu Jia iptables, 1.8.4, Changhyeok Bae linux-firmware, 20190815-new-commits-available, Otavio Salvador libpipeline, 1.5.2, Alexander Kanavin iw, 5.4, Changhyeok Bae x264, r2917-new-commits-available, Anuj Mittal assimp, 5.0.1, Anuj Mittal msmtp, 1.8.7, Alexander Kanavin libxpm, 3.5.13, Armin Kuster libjpeg-turbo, 2.0.4, Anuj Mittal ccache, 3.7.7, Robert Yang ffmpeg, 4.2.2, Alexander Kanavin glib-networking, 2.62.3, Anuj Mittal python3-dbus, 1.2.16, Oleksandr Kravchuk sudo, 1.8.30, Chen Qi piglit, 1.0-new-commits-available, Ross Burton libva-utils, 2.6.0., Anuj Mittal kmscube, git-new-commits-available, Carlos Rafael Giani ncurses, 6.1+20191019, Hongxu Jia u-boot-tools, 2020.01, Marek Vasut at-spi2-core, 2.34.0, Anuj Mittal vim-tiny, 8.2, Tom Rini vim, 8.2, Tom Rini python3-gitdb, 2.0.6, Oleksandr Kravchuk libedit, 20191231-3.1, Khem Raj gstreamer1.0-python, 1.16.2, Anuj Mittal curl, 7.68.0, Armin Kuster hwlatdetect, 1.6, Alexander Kanavin epiphany, 3.34.3.1, Alexander Kanavin grep, 3.4, Denys Dmytriyenko libwebp, 1.1.0, Alexander Kanavin python3-setuptools, 45.0.0, Oleksandr Kravchuk libcap, 2.31, Yi Zhao stress-ng, 0.10.16, Anuj Mittal asciidoc, 8.6.10, Yi Zhao python3-git, 3.0.5, Oleksandr Kravchuk gnu-config, 20190501-new-commits-available, Robert Yang libarchive, 3.4.1, Otavio Salvador ethtool, 5.4, Changhyeok Bae python3-six, 1.14.0, Oleksandr Kravchuk dnf, 4.2.18, Alexander Kanavin xserver-xorg, 1.20.7, Armin Kuster createrepo-c, 0.15.5, Alexander Kanavin file, 5.38, Yi Zhao gstreamer1.0, 1.16.2, Anuj Mittal sed, 4.8, Chen Qi libpcre2, 10.34, Armin Kuster ell, 0.27, Oleksandr Kravchuk TOTAL: attempted=103 succeeded=53(51.46%) failed=50(48.54%) Recipe upgrade statistics per Maintainer: Anuj Mittal -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] newlib: Enable building libstdc++ for newlib based toolchains
Some baremetal applications might require support from libstdc++.
On newlib based toolchains, libstdc++ can be built as a static
library that applications can then link against it.
Pass libsdtc++-(static)dev to LIBC_DEPENDENCIES allowing the
library to be present for cross compilation as well as on
sdk builds.
This also requires to modify the gcc-runtime recipe to
explictly build only libsdtc++ correctly.
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
meta/conf/distro/include/tclibc-newlib.inc | 7 +++
meta/recipes-devtools/gcc/gcc-runtime.inc | 6 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/meta/conf/distro/include/tclibc-newlib.inc
b/meta/conf/distro/include/tclibc-newlib.inc
index 896c0b1..8338003 100644
--- a/meta/conf/distro/include/tclibc-newlib.inc
+++ b/meta/conf/distro/include/tclibc-newlib.inc
@@ -25,12 +25,11 @@ LIBC_DEPENDENCIES = "\
libgloss-dbg \
libgcc-dev \
libgcc-dbg \
+libstdc++-dev \
+libstdc++-staticdev \
"
-# compilerlibs defaults to gcc-runtime, but we get runtime from libgloss
-# we set ASSUME_PROVIDED because we cant set PREFERRED_PROVIDER
-# for compilerlibs since its overridden by tcmode-default
-ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}compilerlibs virtual/crypt"
+ASSUME_PROVIDED += "virtual/crypt"
# Its useful to be able to extend newlib, but we dont provide a native variant
of libgloss
NEWLIB_EXTENDED ?= "libgloss libgcc"
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index d3f8ae8..f035fbd 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -17,6 +17,9 @@ EXTRA_OECONF_PATHS = "\
EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
+EXTRA_OECONF_remove_libc-newlib = "--enable-symvers=gnu"
+EXTRA_OECONF_append_libc-newlib = " --with-newlib"
+
# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
@@ -33,6 +36,9 @@ RUNTIMELIBITM_riscv64 = ""
RUNTIMELIBSSP ?= ""
RUNTIMELIBSSP_mingw32 ?= "libssp"
+# Only build libstdc++ for newlib
+RUNTIMETARGET_libc-newlib = "libstdc++-v3"
+
RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic
${RUNTIMELIBITM} \
${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath',
'', d)} \
"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] machine_dict: Add i686 to the ELF machine dictionary
An error like the following is thrown when building baremetal applications on some x86 architectures: (machine, osabi, abiversion, littleendian, bits) \ = oe.elf.machine_dict(d)[target_os][target_arch] Exception: KeyError: i686 Since the i686 (target_arch) key does not exist in the dictionary. Add the key to fix the error. Signed-off-by: Alejandro Enedino Hernandez Samaniego --- meta/lib/oe/elf.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oe/elf.py b/meta/lib/oe/elf.py index 2562cea..e0c31ff 100644 --- a/meta/lib/oe/elf.py +++ b/meta/lib/oe/elf.py @@ -15,6 +15,7 @@ def machine_dict(d): "aarch64" : (183,0,0, True, 64), "aarch64_be" :(183,0,0, False, 64), "i586" : (3, 0,0, True, 32), +"i686" : (3, 0,0, True, 32), "x86_64": (62, 0,0, True, 64), "epiphany": (4643, 0,0, True, 32), "lm32": (138,0,0, False, 32), -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] ghostscript: Add powerpc64 LE specific objarch.h
Signed-off-by: Khem Raj --- .../ghostscript/powerpc64le/objarch.h | 40 +++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-extended/ghostscript/ghostscript/powerpc64le/objarch.h diff --git a/meta/recipes-extended/ghostscript/ghostscript/powerpc64le/objarch.h b/meta/recipes-extended/ghostscript/ghostscript/powerpc64le/objarch.h new file mode 100644 index 00..a05de29def --- /dev/null +++ b/meta/recipes-extended/ghostscript/ghostscript/powerpc64le/objarch.h @@ -0,0 +1,40 @@ +/* Parameters derived from machine and compiler architecture. */ +/* This file is generated mechanically by genarch.c. */ + +/* Scalar alignments */ + +#define ARCH_ALIGN_SHORT_MOD 2 +#define ARCH_ALIGN_INT_MOD 4 +#define ARCH_ALIGN_LONG_MOD 8 +#define ARCH_ALIGN_PTR_MOD 8 +#define ARCH_ALIGN_FLOAT_MOD 4 +#define ARCH_ALIGN_DOUBLE_MOD 8 + +/* Scalar sizes */ + +#define ARCH_LOG2_SIZEOF_CHAR 0 +#define ARCH_LOG2_SIZEOF_SHORT 1 +#define ARCH_LOG2_SIZEOF_INT 2 +#define ARCH_LOG2_SIZEOF_LONG 3 +#define ARCH_LOG2_SIZEOF_LONG_LONG 3 +#define ARCH_SIZEOF_GX_COLOR_INDEX 8 +#define ARCH_SIZEOF_PTR 8 +#define ARCH_SIZEOF_FLOAT 4 +#define ARCH_SIZEOF_DOUBLE 8 +#define ARCH_FLOAT_MANTISSA_BITS 24 +#define ARCH_DOUBLE_MANTISSA_BITS 53 + +/* Unsigned max values */ + +#define ARCH_MAX_UCHAR ((unsigned char)0xff + (unsigned char)0) +#define ARCH_MAX_USHORT ((unsigned short)0x + (unsigned short)0) +#define ARCH_MAX_UINT ((unsigned int)~0 + (unsigned int)0) +#define ARCH_MAX_ULONG ((unsigned long)~0L + (unsigned long)0) + +/* Miscellaneous */ + +#define ARCH_IS_BIG_ENDIAN 0 +#define ARCH_PTRS_ARE_SIGNED 0 +#define ARCH_FLOATS_ARE_IEEE 1 +#define ARCH_ARITH_RSHIFT 2 +#define ARCH_DIV_NEG_POS_TRUNCATES 1 -- 2.25.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] tcf-agent: Add LCL_STOP_SERVICES for powerpc64 LE
This is same as PPC64 BE
Signed-off-by: Khem Raj
---
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index b4bd4ca63c..e0a07a9375 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -46,6 +46,7 @@ CFLAGS_append_mips = " ${LCL_STOP_SERVICES}"
CFLAGS_append_mips64 = " ${LCL_STOP_SERVICES}"
CFLAGS_append_libc-musl = " ${LCL_STOP_SERVICES}"
CFLAGS_append_powerpc64 = " ${LCL_STOP_SERVICES}"
+CFLAGS_append_powerpc64le = " ${LCL_STOP_SERVICES}"
CFLAGS_append_riscv64 = " ${LCL_STOP_SERVICES}"
do_install() {
--
2.25.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] classes, conf, lib: Add support for powerpc64le
LE is default for modern powerpc64, power8+
PowerPC64 Little Endian Linux ABI specifies Power8 as the minimum ISA.
The basic ABI can run on earlier versions of the 64 bit PowerPC ISA,
but it was helpful to define a new, minimum instruction set for Linux
distribution releases during the switch to Little Endian.
Signed-off-by: Khem Raj
---
meta/classes/libc-package.bbclass | 1 +
meta/classes/meson.bbclass| 2 +-
meta/conf/bitbake.conf| 1 +
meta/lib/oe/elf.py| 2 ++
meta/lib/oe/package_manager.py| 1 +
5 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index de816bcec1..de3b4250c7 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -248,6 +248,7 @@ python package_do_split_gconvs () {
"sh4": " --uint32-align=4 --big-endian ",\
"powerpc": " --uint32-align=4 --big-endian ",\
"powerpc64": " --uint32-align=4 --big-endian ", \
+"powerpc64le": " --uint32-align=4 --little-endian ", \
"mips":" --uint32-align=4 --big-endian ",\
"mipsisa32r6":" --uint32-align=4 --big-endian ",\
"mips64": " --uint32-align=4 --big-endian ",\
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 71f9de1a57..1ef34a999c 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -45,7 +45,7 @@ def meson_cpu_family(var, d):
arch = d.getVar(var)
if arch == 'powerpc':
return 'ppc'
-elif arch == 'powerpc64':
+elif arch == 'powerpc64' or arch == 'powerpc64le':
return 'ppc64'
elif arch == 'armeb':
return 'arm'
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 62b5466b71..3bbe42c2c0 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -11,6 +11,7 @@ baselib = "${BASELIB}"
baselib[vardepvalue] = "${baselib}"
BASELIB = "lib"
BASELIB_powerpc64 = "lib64"
+BASELIB_powerpc64le = "lib64"
# Path prefixes
export base_prefix = ""
diff --git a/meta/lib/oe/elf.py b/meta/lib/oe/elf.py
index 2562cea1dd..43c962c697 100644
--- a/meta/lib/oe/elf.py
+++ b/meta/lib/oe/elf.py
@@ -34,6 +34,7 @@ def machine_dict(d):
"armeb": (40,97,0, False,
32),
"powerpc":(20, 0,0, False,
32),
"powerpc64": (21, 0,0, False,
64),
+"powerpc64le": (21, 0,0, True,
64),
"i386": ( 3, 0,0, True,
32),
"i486": ( 3, 0,0, True,
32),
"i586": ( 3, 0,0, True,
32),
@@ -68,6 +69,7 @@ def machine_dict(d):
"armeb": ( 40,97,0, False,
32),
"powerpc":( 20, 0,0, False,
32),
"powerpc64": ( 21, 0,0, False,
64),
+"powerpc64le": (21, 0,0, True,
64),
"i386": ( 3, 0,0, True,
32),
"i486": ( 3, 0,0, True,
32),
"i586": ( 3, 0,0, True,
32),
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index e15e3c4a31..e96c28b46d 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -107,6 +107,7 @@ def generate_locale_archive(d, rootfs, target_arch,
localedir):
"sh4": ["--uint32-align=4", "--big-endian"],
"powerpc": ["--uint32-align=4", "--big-endian"],
"powerpc64": ["--uint32-align=4", "--big-endian"],
+"powerpc64le": ["--uint32-align=4", "--little-endian"],
"mips": ["--uint32-align=4", "--big-endian"],
"mipsisa32r6": ["--uint32-align=4", "--big-endian"],
"mips64": ["--uint32-align=4", "--big-endian"],
--
2.25.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] gcc: Enable 32bit powerpcle at multi-arch for powerpc64le
Even though we do not expect any legacy ( 32bit ) for LE, linux-yocto does enable the compat code, so enable 32bit support to get that going Signed-off-by: Khem Raj --- meta/recipes-devtools/gcc/gcc-common.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc index 44cba287f3..3dcfdf835f 100644 --- a/meta/recipes-devtools/gcc/gcc-common.inc +++ b/meta/recipes-devtools/gcc/gcc-common.inc @@ -47,6 +47,7 @@ def get_gcc_multiarch_setting(bb, d): "i586":"--enable-targets=all", "i686":"--enable-targets=all", "powerpc": "--enable-targets=powerpc64", +"powerpc64le": "--enable-targets=powerpcle", "mips":"--enable-targets=all", "sparc": "--enable-targets=all", } -- 2.25.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Introduce powerpc64 LE architecture support
This patchset adds base support for building ppc64 in Litte-Endian mode, the linux-yocto changes and qemu related changes will make it buildable target out of box, but that is not yet made available The following changes since commit ecbf203e34484731dcb6acc5e75df79cb86e55dc: sstatesig: Improve debug output if getpwuid() fails (2020-01-16 22:33:09 +) are available in the Git repository at: git://git.yoctoproject.org/poky-contrib kraj/ppc64le http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=kraj/ppc64le Khem Raj (5): classes,conf,lib: Add support for powerpc64le gcc: Enable 32bit powerpcle at multi-arch for powerpc64le openssl: Add powerpc64 LE support tcf-agent: Add LCL_STOP_SERVICES for powerpc64 LE ghostscript: Add powerpc64 LE specific objarch.h meta/classes/libc-package.bbclass | 1 + meta/classes/meson.bbclass| 2 +- meta/conf/bitbake.conf| 1 + meta/lib/oe/elf.py| 2 + meta/lib/oe/package_manager.py| 1 + .../openssl/openssl_1.1.1d.bb | 3 ++ meta/recipes-devtools/gcc/gcc-common.inc | 1 + .../tcf-agent/tcf-agent_git.bb| 1 + .../ghostscript/powerpc64le/objarch.h | 40 +++ 9 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-extended/ghostscript/ghostscript/powerpc64le/objarch.h -- 2.25.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] openssl: Add powerpc64 LE support
Signed-off-by: Khem Raj
---
meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index 458ae7daf4..7fd0f9a269 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -102,6 +102,9 @@ do_configure () {
linux-powerpc64)
target=linux-ppc64
;;
+ linux-powerpc64le)
+ target=linux-ppc64le
+ ;;
linux-riscv32)
target=linux-generic32
;;
--
2.25.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][v2 00/10] Make MIME work on desktops
On Sat, 2020-01-18 at 11:13 +, Richard Purdie wrote: > On Sat, 2020-01-18 at 12:08 +0100, Andreas Müller wrote: > > On Sat, Jan 18, 2020 at 9:40 AM Richard Purdie > > wrote: > > > > V1 -> V2: > > > > * Shelve global path export thingy > > > > * Add me as maintainer of itstool (let's consider 'ü' in my > > > > name > > > > as > > > > test case :) > > > > * Change "to to" to "to" in commit message > > > > * Build shared-mime-info from git to allow automated upgrades > > > > * mime-xdg.bbclass: Be prepared for packages as libreoffice: > > > > Desktop > > > > files > > > > installed are absolut symlinks broken for us. In case other > > > > projects do same: > > > > Offer asolution and guide recipe writers how to handle by > > > > generating warnings > > > > with instructions how to handle. > > > > > > Thanks, this looks good to me. It did generate a warning on > > > master- > > > next > > > builds in many places: > > > > > > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains > > > desktop file with key 'MimeType' but does not inhert mime-xdg: > > > libfm-gtk path '/work/armv7vet2hf-neon-oe-linux- > > > gnueabi/libfm/1.3.1-r0/packages-split/libfm- > > > gtk/usr/share/applications/lxshortcut.desktop' [mime-xdg] > > > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains > > > mime types but does not inhert mime: libfm-mime path > > > '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages- > > > split/libfm-mime/usr/share/mime/packages/libfm.xml' [mime] > > Slipped through - will send a follow up > > Thanks, should be simple at least! :) I've sent a fix out which I think is right... > > > > It also generated: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 > > > > > > which partly is the python2 removal that was in with the test and > > > partly this series since itstool is GPLv3 :(. > > Is there any activity required from my side? > > Well, as things stand this series breaks meta-gplv2. This is > currently > tested on the autobuilder and turns it red. I'm therefore blocked on > merging. > > > > I have to admit I'm not sure how reasonable it is to keep hacking > > > the > > > gplv2 layer to work... > > The question now is really whether we want to continue supporting > meta- > gplv2 with master? > > I don't like the layer, I think there are other approaches we're > going > to need to take going forward and the project may need to send that > message. > > If someone steps up and fixes it, great, we can move forward and I'll > defer that discussion. > > If nobody does, quickly, then I will need to start a discussion about > dropping it from the core YP testing. This patch is blocked until > something changes though :( I figured out how to fix the issues so I've sent patches as well and am rerunning the autobuilder tests. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libfm: Add mime and mime-xdg classes
libfm installs mime types we want in our mime-database and it also uses desktop
files
containing MimeType.
Signed-off-by: Richard Purdie
---
meta/recipes-support/libfm/libfm_1.3.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/libfm/libfm_1.3.1.bb
b/meta/recipes-support/libfm/libfm_1.3.1.bb
index 918fe3ece70..63ae7874b95 100644
--- a/meta/recipes-support/libfm/libfm_1.3.1.bb
+++ b/meta/recipes-support/libfm/libfm_1.3.1.bb
@@ -19,7 +19,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/pcmanfm/libfm-${PV}.tar.xz \
SRC_URI[md5sum] = "c15ecd2c9317e2c385cd3f046d0b61ba"
SRC_URI[sha256sum] =
"96b1244bde41ca0eef0332cfb5c67bb16725dfd102128f3e6f74fadc13a1cfe4"
-inherit autotools pkgconfig gtk-doc gettext features_check
+inherit autotools pkgconfig gtk-doc gettext features_check mime mime-xdg
ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
EXTRA_OECONF = "--with-gtk=3"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Building older releases on modern distros (and vice versa)
On Fri, 2020-01-17 at 14:41 -0800, akuster808 wrote: > I would like to thank you and Intel for taking up this task even > thought > the community seemed to have issues with Centos7 being dropped. > > Is there anything community can do at this point? The work isn't complete, we have a proof of concept so far. The remaining work: * forward port the binutils patch and buildtools-tarball changes to master * create some mechanism in the autobuilder-helper to download and install (or init if already present) a given buildtools tarball for a given host distro before invoking builds. * build a set of buildtools tarballs that cover the major gcc verions we need * release/publish said tarballs * add config to the autobuilder for the stable releases we want to build using this mechanism. * potentially test and debug building older releases Not sure who is going to do this but it isn't trivial and the work certainly isn't done yet. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][v2 00/10] Make MIME work on desktops
On Sat, 2020-01-18 at 12:08 +0100, Andreas Müller wrote: > On Sat, Jan 18, 2020 at 9:40 AM Richard Purdie > wrote: > > > V1 -> V2: > > > * Shelve global path export thingy > > > * Add me as maintainer of itstool (let's consider 'ü' in my name > > > as > > > test case :) > > > * Change "to to" to "to" in commit message > > > * Build shared-mime-info from git to allow automated upgrades > > > * mime-xdg.bbclass: Be prepared for packages as libreoffice: > > > Desktop > > > files > > > installed are absolut symlinks broken for us. In case other > > > projects do same: > > > Offer asolution and guide recipe writers how to handle by > > > generating warnings > > > with instructions how to handle. > > > > Thanks, this looks good to me. It did generate a warning on master- > > next > > builds in many places: > > > > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains desktop > > file with key 'MimeType' but does not inhert mime-xdg: libfm-gtk path > > '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-gtk/usr/share/applications/lxshortcut.desktop' > > [mime-xdg] > > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains mime > > types but does not inhert mime: libfm-mime path > > '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-mime/usr/share/mime/packages/libfm.xml' > > [mime] > Slipped through - will send a follow up Thanks, should be simple at least! :) > > It also generated: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 > > > > which partly is the python2 removal that was in with the test and > > partly this series since itstool is GPLv3 :(. > Is there any activity required from my side? Well, as things stand this series breaks meta-gplv2. This is currently tested on the autobuilder and turns it red. I'm therefore blocked on merging. > > I have to admit I'm not sure how reasonable it is to keep hacking the > > gplv2 layer to work... The question now is really whether we want to continue supporting meta- gplv2 with master? I don't like the layer, I think there are other approaches we're going to need to take going forward and the project may need to send that message. If someone steps up and fixes it, great, we can move forward and I'll defer that discussion. If nobody does, quickly, then I will need to start a discussion about dropping it from the core YP testing. This patch is blocked until something changes though :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][v2 00/10] Make MIME work on desktops
On Sat, Jan 18, 2020 at 9:40 AM Richard Purdie wrote: > > > > V1 -> V2: > > * Shelve global path export thingy > > * Add me as maintainer of itstool (let's consider 'ü' in my name as > > test case :) > > * Change "to to" to "to" in commit message > > * Build shared-mime-info from git to allow automated upgrades > > * mime-xdg.bbclass: Be prepared for packages as libreoffice: Desktop > > files > > installed are absolut symlinks broken for us. In case other > > projects do same: > > Offer asolution and guide recipe writers how to handle by > > generating warnings > > with instructions how to handle. > > Thanks, this looks good to me. It did generate a warning on master-next > builds in many places: > > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains desktop > file with key 'MimeType' but does not inhert mime-xdg: libfm-gtk path > '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-gtk/usr/share/applications/lxshortcut.desktop' > [mime-xdg] > WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains mime types > but does not inhert mime: libfm-mime path > '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-mime/usr/share/mime/packages/libfm.xml' > [mime] Slipped through - will send a follow up > > It also generated: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 > > which partly is the python2 removal that was in with the test and > partly this series since itstool is GPLv3 :(. Is there any activity required from my side? > > I have to admit I'm not sure how reasonable it is to keep hacking the > gplv2 layer to work... > > Cheers, > > Richard > Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] [RFC PATCH] python: remove Python 2 and all supporting classes
On Fri, 2020-01-17 at 14:16 +, Ross Burton wrote: > Python 2 ceased being maintained on the 1st January 2020. We've > already > removed all users of it from oe-core so the final step is to move the > recipe and supporting classes to meta-python2. > > The following are removed in this commit: > - python and python-native 2.7.17 > - python-setuptools > - The classes pythonnative, pythondir, distutils, setuptools > > Signed-off-by: Ross Burton Thanks Ross. I tested this on the autobuilder, only 'surprise' is meta- gplv2 fails: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 (python dependency of mc). Just delete mc from that layer? Some of the other failures there are from other bits of -next. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][v2 00/10] Make MIME work on desktops
On Fri, 2020-01-17 at 22:28 +0100, Andreas Müller wrote: > On fresh images file-browsers do not know how to open files and > usually open a > dialog with ALL applications available on the machine. This is not > what users > are used to when working with linux: For just one application > installed per > Mime-Type, the application is opened automatically. > > To get a working MIME on desktop it needs two 'databases' on target: > > 1. Mime-Types: This is handled by mime.bbclass and creates database > in >/usr/share/mime/mime.cache. > 2. Mime associations: A simple text-list of pairs Mime-Type <-> > application >in /usr/share/applications/mimeinfo.cache > > This patch series updates/implements/enhances both parts to get > images work as > expected. > > @Khem: This series creates many QA warnings for layers in meta- > openembedded and > a patch series fixing many was prepared [1]. Once this series get's > applied (or > you ask for it) I can send them out. > > [1] > https://github.com/schnitzeltony/meta-openembedded/tree/work-2020-01 > > V1 -> V2: > * Shelve global path export thingy > * Add me as maintainer of itstool (let's consider 'ü' in my name as > test case :) > * Change "to to" to "to" in commit message > * Build shared-mime-info from git to allow automated upgrades > * mime-xdg.bbclass: Be prepared for packages as libreoffice: Desktop > files > installed are absolut symlinks broken for us. In case other > projects do same: > Offer asolution and guide recipe writers how to handle by > generating warnings > with instructions how to handle. Thanks, this looks good to me. It did generate a warning on master-next builds in many places: WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains desktop file with key 'MimeType' but does not inhert mime-xdg: libfm-gtk path '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-gtk/usr/share/applications/lxshortcut.desktop' [mime-xdg] WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains mime types but does not inhert mime: libfm-mime path '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-mime/usr/share/mime/packages/libfm.xml' [mime] It also generated: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 which partly is the python2 removal that was in with the test and partly this series since itstool is GPLv3 :(. I have to admit I'm not sure how reasonable it is to keep hacking the gplv2 layer to work... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
