gnugp1: Fix build errors with gcc-10
Testing, NormalPublic
Actions

Assigned To

Authored By

	cbiedl
	Jan 4 2021, 8:35 AM

Description

The gnugp1 package fails to build with gcc-10 This is a direct result of gcc defaulting to -fno-common, see also https://gcc.gnu.org/gcc-10/porting_to.html.

A simple but somewhat ugly fix was to tweak the build options to restore the previous behaviour, this is what Fedora did in https://src.fedoraproject.org/rpms/gnupg1/c/a44e9b1c0c362891cb4a3a1f992e73dd614cb31b?branch=master. However, I would prefer a nicer approach. Rewriting the code might become somewhat bigger work, I tried a few things but no luck. So I'd prefer to enhance the definition of EXTERN_UNLESS_MAIN_MODULE as for example:

--- a/g10/options.h
+++ b/g10/options.h
@@ -29,6 +29,8 @@
 /* Norcraft can't cope with common symbols */
 #if defined (__riscos__) && !defined (INCLUDED_BY_MAIN_MODULE)
 #define EXTERN_UNLESS_MAIN_MODULE extern
+#elif defined (__GNUC__) && __GNUC__ >= 10
+#define EXTERN_UNLESS_MAIN_MODULE __attribute__((__common__))
 #else
 #define EXTERN_UNLESS_MAIN_MODULE
 #endif

Thoughts?

Details

External Link: https://bugs.debian.org/957293
Version: 1.4.23

Revisions and Commits

rG GnuPG
	rGa831f80e044a tools: Fix for RISC OS which doesn't allow COMMON section.
	rG9ad423d7218c gpg: Avoid use of COMMON section for all cases.

Related Objects

Mentioned In: T5360: scute: -fcommon needed when building with gcc-10

Event Timeline

cbiedl created this task.Jan 4 2021, 8:35 AM

You may want to check that clang supports this attribute as well.

• werner added a project: gnupg (gpg14).Jan 4 2021, 9:14 AM

According to list of attributes in the clang 12 documention, there is no such attribute in clang. However, the clang-11 compiler (as seen in Debian) does not define __GNUC__, so the proposed patch does not affect the status when building with clang.

Sure that the FreeBSD compiler does not define it? I am pretty sure it does.

Thus better add a

&& !defined(__clang__)

• werner triaged this task as Normal priority.Jan 5 2021, 9:06 AM

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

Also, FreeBSD just enabled -fcommon to deal with that situation: https://svnweb.freebsd.org/ports/head/security/gnupg1/Makefile?revision=545570&view=markup

As a result, I'm inclined to just add -fcommon in the compile options. Either unconditionally, or after some autoconf check could be done whether it's really required, or limited to gcc and clang. But I doubt that is worth the efforts and would just stick to the first option.

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

--- a/configure.ac
+++ b/configure.ac
@@ -1411,10 +1411,10 @@ if test "$GCC" = yes; then
     # warning options and the user should have a chance of overriding
     #them.
     if test "$USE_MAINTAINER_MODE" = "yes"; then
-        CFLAGS="$CFLAGS -Wall -Wcast-align -Wshadow -Wstrict-prototypes"
+        CFLAGS="$CFLAGS -Wall -fcommon -Wcast-align -Wshadow -Wstrict-prototypes"
         CFLAGS="$CFLAGS -Wformat-nonliteral"
     else
-        CFLAGS="$CFLAGS -Wall"
+        CFLAGS="$CFLAGS -Wall -fcommon"
     fi
 
     # This is handy for debugging so the compiler doesn't rearrange

cbiedl mentioned this in T5360: scute: -fcommon needed when building with gcc-10.Mar 25 2021, 1:35 PM

Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

• gniibe added a commit: rGa831f80e044a: tools: Fix for RISC OS which doesn't allow COMMON section..Aug 27 2021, 3:49 AM

• gniibe added a commit: rG9ad423d7218c: gpg: Avoid use of COMMON section for all cases..

• gniibe added a project: Restricted Project.Dec 8 2021, 9:10 AM

• werner changed the task status from Open to Testing.Sep 22 2022, 10:58 AM

• werner removed a project: Restricted Project.