gnugp1: Fix build errors with gcc-10
Open, NormalPublic

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
cbiedl created this task.Mon, Jan 4, 8:35 AM
werner added a subscriber: werner.Mon, Jan 4, 9:14 AM

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

cbiedl added a comment.Mon, Jan 4, 1:16 PM

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.

werner added a comment.Mon, Jan 4, 1:31 PM

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

werner added a comment.EditedMon, Jan 4, 1:32 PM

Thus better add a

&& !defined(__clang__)
werner triaged this task as Normal priority.Tue, Jan 5, 9:06 AM
cbiedl added a comment.Wed, Jan 6, 3:55 PM

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.

werner added a comment.Wed, Jan 6, 4:03 PM

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.

cbiedl added a comment.Wed, Jan 6, 5:42 PM

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