kilian.brandt@...
Hi Khem, thanks for your reply! Now I am a bit confused. Marek has send me another recipe:
Do you know if that is allready fixed for kernel 5,2+ ? Best regards! |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
[meta-cgl][PATCH] pacemaker: Fix build with -fno-common
Yu, Mingli
From: Mingli Yu <mingli.yu@...>
Starting with GCC >= 10.x, -fno-common is used as default instead of -fcommon. Make the function definiton extern to fix the build failure. Set the default OCF_ROOT_DIR to $libdir/ocf to make the resource agents components more compatible. Signed-off-by: Mingli Yu <mingli.yu@...> --- .../0001-Mark-declaration-with-extern.patch | 46 +++++++++++++++++++ ...maker-set-OCF_ROOT_DIR-to-libdir-ocf.patch | 32 +++++++++++++ .../recipes-cgl/pacemaker/pacemaker_2.0.3.bb | 2 + 3 files changed, 80 insertions(+) create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch create mode 100644 meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch new file mode 100644 index 0000000..5729447 --- /dev/null +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-Mark-declaration-with-extern.patch @@ -0,0 +1,46 @@ +From e1abd3b7c7a0122813e4d0abdb079df10104882c Mon Sep 17 00:00:00 2001 +From: Mingli Yu <mingli.yu@...> +Date: Thu, 3 Sep 2020 04:44:09 +0000 +Subject: [PATCH] Mark declaration with extern + +Fixes build with gcc 10+ + +Upstream-Status: Pending + +Signed-off-by: Mingli Yu <mingli.yu@...> +--- + daemons/attrd/pacemaker-attrd.h | 4 ++-- + daemons/execd/pacemaker-execd.h | 2 +- + 2 files changed, 3 insertions(+), 3 deletions(-) + +diff --git a/daemons/attrd/pacemaker-attrd.h b/daemons/attrd/pacemaker-attrd.h +index cc8e29ee1..76778915e 100644 +--- a/daemons/attrd/pacemaker-attrd.h ++++ b/daemons/attrd/pacemaker-attrd.h +@@ -106,8 +106,8 @@ typedef struct attribute_value_s { + gboolean seen; + } attribute_value_t; + +-crm_cluster_t *attrd_cluster; +-GHashTable *attributes; ++extern crm_cluster_t *attrd_cluster; ++extern GHashTable *attributes; + + #define attrd_send_ack(client, id, flags) \ + crm_ipcs_send_ack((client), (id), (flags), "ack", __FUNCTION__, __LINE__) +diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h +index 4a52d9183..dab3ccdbe 100644 +--- a/daemons/execd/pacemaker-execd.h ++++ b/daemons/execd/pacemaker-execd.h +@@ -20,7 +20,7 @@ + # include <gnutls/gnutls.h> + # endif + +-GHashTable *rsc_list; ++extern GHashTable *rsc_list; + + typedef struct lrmd_rsc_s { + char *rsc_id; +-- +2.26.2 + diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch new file mode 100644 index 0000000..1ff9c7d --- /dev/null +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch @@ -0,0 +1,32 @@ +From 3ca78a6441eefc26f18211375b18205ed6fc28c6 Mon Sep 17 00:00:00 2001 +From: Mingli Yu <mingli.yu@...> +Date: Thu, 3 Sep 2020 05:26:36 +0000 +Subject: [PATCH] pacemaker: set OCF_ROOT_DIR to $libdir/ocf + +* Set the default OCF_ROOT_DIR to $libdir/ocf + to make the resource agents components more + compatible + +Upstream-Status: Pending + +Signed-off-by: Mingli Yu <mingli.yu@...> +--- + configure.ac | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/configure.ac b/configure.ac +index 58d39cdc0..eb4275560 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -315,7 +315,7 @@ dnl This defaults to /usr/lib rather than libdir because it's determined by the + dnl OCF project and not pacemaker. Even if a user wants to install pacemaker to + dnl /usr/local or such, the OCF agents will be expected in their usual + dnl location. However, we do give the user the option to override it. +-OCF_ROOT_DIR="/usr/lib/ocf" ++OCF_ROOT_DIR="$libdir/ocf" + AC_ARG_WITH([ocfdir], + [AS_HELP_STRING([--with-ocfdir=DIR], + [OCF resource agent root directory (advanced option: changing this may break other cluster components unless similarly configured) @<:@/usr/lib/ocf@:>@])], +-- +2.26.2 + diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb index 9b63acd..56f3bc4 100644 --- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb +++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_2.0.3.bb @@ -16,6 +16,8 @@ DEPENDS = "corosync libxslt libxml2 gnutls resource-agents libqb python3-native" SRC_URI = "git://github.com/ClusterLabs/${BPN}.git \ file://0006-Fix-tools-Fix-definition-of-curses_indented_printf.patch \ file://0001-Fix-python3-usage.patch \ + file://0001-Mark-declaration-with-extern.patch \ + file://0001-pacemaker-set-OCF_ROOT_DIR-to-libdir-ocf.patch \ file://volatiles \ file://tmpfiles \ " -- 2.26.2 |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Query on building applications and catch exceptions across different shared libraries
On Wed, Sep 2, 2020 at 8:06 PM SIMON BABY <simonkbaby@...> wrote:
OK please add it to your CXXFLAGS and see if it helps.
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Query on building applications and catch exceptions across different shared libraries
SIMON BABY
No I am not using -fexceptions compiler flag .
toggle quoted message
Show quoted text
Rgds Simon On Wednesday, September 2, 2020, Khem Raj <raj.khem@...> wrote: On Wed, Sep 2, 2020 at 5:18 PM SIMON BABY <simonkbaby@...> wrote: |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Query on building applications and catch exceptions across different shared libraries
On Wed, Sep 2, 2020 at 5:18 PM SIMON BABY <simonkbaby@...> wrote:
are you using -fexceptions to compile your application ? regards |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Query on building applications and catch exceptions across different shared libraries
SIMON BABY
Hello, I have an issue with my throw , catch code in c++. If i throw an error after the openssl library call, my application crashes. If my application wishes to throw and catch exceptions across different shared libraries do we have any specific settings I can add in my bitbake recipe? regards Simon |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
On Wed, Sep 2, 2020 at 4:32 AM Marek Belisko <marek.belisko@...> wrote:
in this case you might be lucky we already have recipe http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/socketcan/can-isotp_git.bb?h=master its blacklisted because it needs work to fix build on 5.2+ kernel I would really appreciate any help ! Best regards,marek |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Marek Belisko
On Wed, Sep 2, 2020 at 1:13 PM <kilian.brandt@...> wrote:
PLease take a look at : https://www.yoctoproject.org/docs/2.6/kernel-dev/kernel-dev.html#working-with-out-of-tree-modules where it is described how to compile out of tree modules. marek |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
kilian.brandt@...
Hey community,
I'm trying to use this library [can-isotp][1] on a Jetson TX2 Board. The version of the running OS is: 0.0.8 (dunfell).
From the docs of the library I get the following instructions:
```
DOWNLOAD and BUILD 1. Download repository and enter the repositories root directory git clone https://github.com/hartkopp/can-isotp.git cd can-isotp 2. Build ISO-TP kernel module Ensure build dependencies are installed. E.g. for Debian (or Ubuntu): sudo apt-get install build-essential linux-headers-$(uname -r) To build: (you need to be in the repositories root path) make To install (optional): sudo make modules_install 3. When the PF_CAN core module is loaded ('modprobe can') the ISO-TP module can be loaded into the kernel with insmod ./net/can/can-isotp.ko When the can-isotp.ko module has been installed into the Linux Kernels modules directory (e.g. with 'make modules_install') the module should load automatically when opening a CAN_ISOTP socket. ```
I have some questions about that procedure. Can anybody give me an hint on how to install this module? Do I have to create a completly new yocto image or is there any way to install kernel modules afterwards? I tried to copy the folder onto the TX2 and install it by hand, but (as to be expected) the make command is not found. I would really appreciate any help ! Best regards, [1]: https://github.com/hartkopp/can-isotp |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
[PATCH yocto-autobuilder-helper] scripts/send-qa-email: Update to dedicated push capable domain
Michael Halstead
Signed-off-by: Michael Halstead <mhalstead@...>
--- scripts/send-qa-email | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/send-qa-email b/scripts/send-qa-email index abc17e2..f38c876 100755 --- a/scripts/send-qa-email +++ b/scripts/send-qa-email @@ -70,10 +70,10 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir: elif basebranch: cloneopts = ["--branch", basebranch] try: - subprocess.check_call(["git", "clone", "git@...:yocto-testresults", tempdir, "--depth", "5"] + cloneopts) + subprocess.check_call(["git", "clone", "git@...:yocto-testresults", tempdir, "--depth", "5"] + cloneopts) except subprocess.CalledProcessError: print("No comparision branch found, falling back to master") - subprocess.check_call(["git", "clone", "git@...:yocto-testresults", tempdir, "--depth", "5"]) + subprocess.check_call(["git", "clone", "git@...:yocto-testresults", tempdir, "--depth", "5"]) # If the base comparision branch isn't present regression comparision won't work # at least until we can tell the tool to ignore internal branch information -- 2.26.2 |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Yocto Project Status WW35'20
Stephen Jolley
Current Dev Position: YP 3.2 M3 Next Deadline: YP 3.2 M3 Feature Freeze - Now
Next Team Meetings:
Key Status/Updates:
You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.
YP 3.2 Milestone Dates:
Planned upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Recipies version of incoming October Gatesgarth release.
On Tue, 1 Sep 2020 at 13:16, Yocto_user <avinashyadav94it@...> wrote:
I don't think any of us have crystal balls to predict the exact package versions we'll be using in October for the next release. We're close to the feature freeze point but high priority recipe updates could still be taken after that time. Why do you think you need this information? If you explain your concerns hopefully we can find a different way to provide the answers you need. -- Paul Barker Konsulko Group |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Recipies version of incoming October Gatesgarth release.
Yocto_user
Hi,
Is there any way to know all the recipes version detail that will come with Yocto 3.2 Gatesgarth ?? |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Information about Yocto Dunfell components version
#dunfell
On Tue, 1 Sep 2020 at 11:25, Josef Holzmayr-Khosh Amoz
<jester@...> wrote: Also worth noting: The exact versions used will depend on which commit from the dunfell branch you choose. You should follow updates to the stable branch to get the latest security fixes for your packages so the versions should not be perfectly static anyway. -- Paul Barker Konsulko Group |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Private: Re: [yocto] Information about Yocto Dunfell components version
#dunfell
Josef Holzmayr
Well if it's not there, then it's not there. If something is not provided by a recipe, then it obviously has no defined version. Please note though that package/recipe names are not directly comparable between distributions like Ubuntu and the Yocto project ecosystem, as the names might differ slightly. Example: libtiff seems to be just "tiff". Am Di., 1. Sept. 2020 um 12:55 Uhr schrieb Yocto_user <avinashyadav94it@...>: Thanks Josef Holzmayr-Khosh Amoz for the link, but still few components version is missing i.e. |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Re: Information about Yocto Dunfell components version
#dunfell
Josef Holzmayr
Insert the package names into http://layers.openembedded.org/layerindex/branch/dunfell/recipes and see for yourself :) Greetz Am Di., 1. Sept. 2020 um 12:22 Uhr schrieb Yocto_user <avinashyadav94it@...>: Hi All, |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Information about Yocto Dunfell components version
#dunfell
Yocto_user
Hi All,
I read the Dunfell release notes but couldn't find the version detail of following components:
Please give me the version detail of these components, we are planning to use dunfell but before that we needed the version detail of all these components in Yocto. |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
[meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)
Peter Kjellerstedt
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...>
--- ...th-GCC-10-which-uses-fno-common-by-d.patch | 93 +++++++++++++++++++ recipes-support/gnupg/gnupg_1.4.7.bb | 3 +- 2 files changed, 95 insertions(+), 1 deletion(-) create mode 100644 recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch diff --git a/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch new file mode 100644 index 0000000..2f84155 --- /dev/null +++ b/recipes-support/gnupg/gnupg-1.4.7/0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch @@ -0,0 +1,93 @@ +From 1d0141d77d4f81cfa3213370fb7eeddbf53fc085 Mon Sep 17 00:00:00 2001 +From: Peter Kjellerstedt <pkj@...> +Date: Tue, 1 Sep 2020 00:29:22 +0200 +Subject: [PATCH] Make it build with GCC 10 (which uses -fno-common by default) + +Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...> +--- + g10/options.h | 3 +-- + include/cipher.h | 2 +- + include/iobuf.h | 2 +- + include/memory.h | 2 +- + include/mpi.h | 2 +- + tools/mpicalc.c | 1 + + 6 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/g10/options.h b/g10/options.h +index c5f0f22..33ed333 100644 +--- a/g10/options.h ++++ b/g10/options.h +@@ -28,8 +28,7 @@ + #include "packet.h" + + #ifndef EXTERN_UNLESS_MAIN_MODULE +-/* Norcraft can't cope with common symbols */ +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE) ++#if !defined (INCLUDED_BY_MAIN_MODULE) + #define EXTERN_UNLESS_MAIN_MODULE extern + #else + #define EXTERN_UNLESS_MAIN_MODULE +diff --git a/include/cipher.h b/include/cipher.h +index 168ab41..794c12b 100644 +--- a/include/cipher.h ++++ b/include/cipher.h +@@ -109,7 +109,7 @@ struct gcry_md_context { + typedef struct gcry_md_context *MD_HANDLE; + + #ifndef EXTERN_UNLESS_MAIN_MODULE +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE) ++#if !defined (INCLUDED_BY_MAIN_MODULE) + #define EXTERN_UNLESS_MAIN_MODULE extern + #else + #define EXTERN_UNLESS_MAIN_MODULE +diff --git a/include/iobuf.h b/include/iobuf.h +index a1d58c9..25f682b 100644 +--- a/include/iobuf.h ++++ b/include/iobuf.h +@@ -73,7 +73,7 @@ struct iobuf_struct { + }; + + #ifndef EXTERN_UNLESS_MAIN_MODULE +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE) ++#if !defined (INCLUDED_BY_MAIN_MODULE) + #define EXTERN_UNLESS_MAIN_MODULE extern + #else + #define EXTERN_UNLESS_MAIN_MODULE +diff --git a/include/memory.h b/include/memory.h +index 895d8a7..217d316 100644 +--- a/include/memory.h ++++ b/include/memory.h +@@ -87,7 +87,7 @@ unsigned secmem_get_flags(void); + #define DBG_MEMSTAT memory_stat_debug_mode + + #ifndef EXTERN_UNLESS_MAIN_MODULE +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE) ++#if !defined (INCLUDED_BY_MAIN_MODULE) + #define EXTERN_UNLESS_MAIN_MODULE extern + #else + #define EXTERN_UNLESS_MAIN_MODULE +diff --git a/include/mpi.h b/include/mpi.h +index 81061d3..d529bda 100644 +--- a/include/mpi.h ++++ b/include/mpi.h +@@ -38,7 +38,7 @@ + #include "memory.h" + + #ifndef EXTERN_UNLESS_MAIN_MODULE +-#if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE) ++#if !defined (INCLUDED_BY_MAIN_MODULE) + #define EXTERN_UNLESS_MAIN_MODULE extern + #else + #define EXTERN_UNLESS_MAIN_MODULE +diff --git a/tools/mpicalc.c b/tools/mpicalc.c +index 1df27d9..647dfbd 100644 +--- a/tools/mpicalc.c ++++ b/tools/mpicalc.c +@@ -30,6 +30,7 @@ + #include <stdlib.h> + #include <ctype.h> + ++#define INCLUDED_BY_MAIN_MODULE 1 + #include "util.h" + #include "mpi.h" + #include "i18n.h" diff --git a/recipes-support/gnupg/gnupg_1.4.7.bb b/recipes-support/gnupg/gnupg_1.4.7.bb index 6a950fd..6258809 100644 --- a/recipes-support/gnupg/gnupg_1.4.7.bb +++ b/recipes-support/gnupg/gnupg_1.4.7.bb @@ -20,7 +20,8 @@ SRC_URI = "${GNUPG_MIRROR}/gnupg/gnupg-${PV}.tar.bz2 \ file://CVE-2013-4242.patch \ file://fix-ustar-check-issue.patch \ file://0001-Make-it-build-with-gettext-0.20.patch \ - " + file://0001-Make-it-build-with-GCC-10-which-uses-fno-common-by-d.patch \ + " SRC_URI[md5sum] = "b06a141cca5cd1a55bbdd25ab833303c" SRC_URI[sha256sum] = "69d18b7d193f62ca27ed4febcb4c9044aa0c95305d3258fe902e2fae5fc6468d" |
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
M+ & H bugs with Milestone Movements WW35
Stephen Jolley
All,
YP M+ or high bugs which moved to a new milestone in WW35 are listed below:
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
Enhancements/Bugs closed WW35!
Stephen Jolley
All,
The below were the owners of enhancements or bugs closed during the last week!
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||
|