rpms/pacemaker
5
0
Fork 0
Code Issues Pull Requests Releases Activity

2.0.3-2 (potentially) - make project buildable with GCC 10

Browse Source 
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
This commit is contained in:
Jan Pokorný 2020-01-27 23:19:51 +01:00
parent 5d2275ed5a
commit 01e21f8b68
No known key found for this signature in database
GPG Key ID: 61BBB23A9E8F8DE2
2 changed files with 64 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
Build-get-ready-for-implicit-fno-common-with-GCC10.patch Normal file
View File

@ -0,0 +1,62 @@
From 898d369f3bc770c0db2ad3973c204e6d11ec0e0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Pokorn=C3=BD?= <jpokorny@redhat.com>
Date: Tue, 21 Jan 2020 18:24:44 +0100
Subject: [PATCH] Build: get ready for implicit -fno-common with upcoming GCC
10
Currently, -fno-common yields (and only yields, slightly restructured):
> /usr/bin/ld:
> pacemaker_execd-execd_commands.o:
> pcmk/daemons/execd/pacemaker-execd.h:23:
> multiple definition of `rsc_list';
> + pacemaker_execd-pacemaker-execd.o:
> pcmk/daemons/execd/pacemaker-execd.h:23:
> first defined here
>
> pacemaker_execd-execd_alerts.o:
> pcmk/daemons/execd/pacemaker-execd.h:23:
> multiple definition of `rsc_list';
> + pacemaker_execd-pacemaker-execd.o:
> pcmk/daemons/execd/pacemaker-execd.h:23:
> first defined here
>
> collect2: error: ld returned 1 exit status
The problem is that a global (with external linkage) variable without
explicit "extern" stands for "tentative definition" (as opposed to mere
reference to existing object with external linkage otherwise),
and these won't get automagically merged in -fno-common case (which
is going to be a default in upcoming GCC 10).
Solution is to explicitly add "extern" storage-class specifiers
at what's indeed meant as non-tentative reference in the header
files that are going to be included from various translation
units that will end up in the same link.
No more attempts at finding these was performed, just the only instance
that got hit in practice (see above) receives this treatment, since
manual work simply doesn't scale. Either a static analysis can be
employed to mark other potential show-stoppers, or we'll just deal
with the issues on case-by-case basis (with the gargantuan assistence
of CI systems).
References:
https://gcc.gnu.org/gcc-10/porting_to.html#common
---
daemons/execd/pacemaker-execd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemons/execd/pacemaker-execd.h b/daemons/execd/pacemaker-execd.h
index 4a52d91834..dab3ccdbee 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;

3
pacemaker.spec
View File

@ -14,7 +14,7 @@
## can be incremented to build packages reliably considered "newer"
## than previously built packages with the same pcmkversion)
%global pcmkversion 2.0.3
%global specversion 1
%global specversion 2
## Upstream commit (or git tag, such as "Pacemaker-" plus the
## {pcmkversion} macro for an official release) to use for this package
@ -144,6 +144,7 @@ Source0: https://github.com/%{github_owner}/%{name}/archive/%{commit}/%{na
Source1: https://github.com/%{github_owner}/%{nagios_name}/archive/%{nagios_hash}/%{nagios_name}-%{nagios_hash}.tar.gz
# ---
Patch0: Build-fix-unability-to-build-with-Inkscape-1.0-beta-.patch
Patch1: https://github.com/ClusterLabs/pacemaker/commit/898d369f3bc770c0db2ad3973c204e6d11ec0e0f.patch#/Build-get-ready-for-implicit-fno-common-with-GCC10.patch
Requires: resource-agents
Requires: %{name}-libs%{?_isa} = %{version}-%{release}