Project

General

Profile

Actions

Bug #286

closed

"-fcommon" support in gcc version 10 - coreinfo "multiple definition of" build failure

Added by James Feeney over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/03/2020
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

Copied from: https://github.com/seemoo-lab/owl/issues/32

"Starting from the upcoming GCC release 10, the default of -fcommon option will change to -fno-common - this leads to build error"

Copied from man 1 gcc:


-fcommon

In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the "extern" keyword, which do not allocate storage.

The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit.

The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors.


So then, make -C payloads/coreinfo ends with:

/usr/bin/ld: /var/src/coreboot/coreboot/payloads/coreinfo/build/libpayload/bin/../lib/libpayload.a(exception.libc.o):/var/src/coreboot/coreboot/payloads/libpayload/include/x86/arch/exception.h:64: multiple definition of `__packed';
/var/src/coreboot/coreboot/payloads/coreinfo/build/libpayload/bin/../lib/libpayload.a(main.libc.o):/var/src/coreboot/coreboot/payloads/libpayload/include/x86/arch/exception.h:64: first defined here
...

Trying to simplistically prepend CFLAGS=' -fcommon ' make -C payloads/coreinfo just changes the build flow, giving:
cc1: fatal error: /var/src/coreboot/coreboot/payloads/coreinfo/build/libpayload/include/kconfig.h: No such file or directory

Trying to judiciously add a CFLAGS += -fcommon to the payloads/coreinfo/Makefile is beyond me. It changes nothing and produces the same original "multiple definition of" error.

Somebody who knows more about this, please comment.

Actions #1

Updated by James Feeney over 3 years ago

Arch Linux gcc 10.2.0-3

Actions #2

Updated by James Feeney over 3 years ago

Downgrading to gcc8 makes no difference, so this problem with linking apparently has nothing to do with the version of gcc. In Arch Linux, ld here is part of binutils 2.35.1-1.

Actions #3

Updated by James Feeney over 3 years ago

Hmm - I did a git pull today, 2020 Nov 12, rebuilt coreinfo, and now everything links without problem. Whatever - this issue has resolved itself.

Actions #4

Updated by Nico Huber over 3 years ago

  • Status changed from New to Closed

Sorry this tracker is not very active. Thanks for your report, anyway. It was the right thing to do :)

The issue should be fixed with commit: c98baa7a80 (libpayload: Add compiler.h to compiler parameters). As you already confirmed it's working, I'll close this.

Actions

Also available in: Atom PDF