[Bug ld/23350] multiple prevailing defs for unused variable in lto mode

[dobonachea at lbl dot gov]

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.