https://sourceware.org/bugzilla/show_bug.cgi?id=23350
Dan Bonachea <dobonachea at lbl dot gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dobonachea at lbl dot gov --- Comment #9 from Dan Bonachea <dobonachea at lbl dot gov> --- We recently hit what appears to be this same problem with our software. I stumbled upon a workaround, which is to declare one of the tentative definitions as extern. Here's a demonstration applied to the code from comment #6: $ gcc --version gcc (GCC) 9.2.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ tail *.c ==> lib.c <== int wrl; extern int a() { return 0; } ==> main.c <== #ifdef WORKAROUND extern int wrl; #else int wrl; #endif int main () { return 0; } $ gcc -c -flto main.c && gcc -c -flto lib.c && gcc-ar rusc lib.a lib.o && gcc -flto main.o lib.a lib.a lto1: fatal error: multiple prevailing defs for 'a' compilation terminated. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status $ gcc -DWORKAROUND -c -flto main.c && gcc -c -flto lib.c && gcc-ar rusc lib.a lib.o && gcc -flto main.o lib.a lib.a In our case we are always providing a common-block definition from inside the library, so the workaround just meant declaring as extern in the library header file which is the declaration client objects see. Probably not applicable to all situations, but good enough to solve our problem. Hope this helps.. -- You are receiving this mail because: You are on the CC list for the bug.