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. > > As seen, I bet problem is in conftstm.o file (for which I can't see > how it's created). Probably the file is missing declaration of > nm_test_var and so that it's implicitly deduced to be int > nm_test_var().
nm_test_var is defined as: char nm_test_var; The test works by running nm on this file, parsing the output, and then generating a C file which inserts references to all the exported symbols it finds. Then this is linked with the original file. With a "normal" compiler and -fno-common nm_test_var goes in BSS and will be marked "B" in the nm output. 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). It's really unfortunate that LTO breaks nm in this way. But even if this configure test didn't fail I suspect subsequent users of $global_symbol_pipe will expect nm to work properly and it won't. I'm not 100% sure which libtool features will be affected by this configuration failure. It doesn't fatally stop the configure script. Probably dlpreopen won't work at all? It's also unfortunate that since there is no way to directly reference symbol values in standard C, a common way to do so is with dummy array or function declarations, and lo and behold LTO apparently breaks this too... Cheers, Nick