On 2020-01-07, Nick Bowler <nbow...@draconx.ca> wrote: > On 1/7/20, Martin Liška <mli...@suse.cz> wrote: >> nm -B detection fails to be detected with -flto and -fno-common CFLAGS: >> >> configure:6307: checking command to parse /usr/bin/nm -B output from gcc >> object > [...] >> configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 >> -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables >> -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 >> -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables >> -fasynchronous-unwind-tables -fstack-clash-protection >> -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 >> conftest.c:18:12: error: variable 'nm_test_var' redeclared as function >> 18 | extern int nm_test_var(); >> | ^ >> conftest.c:4:6: note: previously declared here >> 4 | relocations are performed -- see ld's documentation on >> pseudo-relocs. */ >> | ^ >> lto1: fatal error: errors during merging of translation units >> compilation terminated. [...] > However, LTO breaks nm really badly and with -fno-common this variable > gets marked as "T" in the nm output. So it is indistinguishable from > functions and when the C file is generated, a function declaration for > nm_test_var is emitted (if it was correctly marked "B", then a variable > declaration will be emitted).
Workaround: add -ffat-lto-objects to CFLAGS so you get proper symbol tables in object files and then set NM='nm --plugin ""' to completely disable the busted LTO support in nm. For example: ./configure CFLAGS='-flto -fno-common -ffat-lto-objects' NM='nm --plugin ""'
