[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: checking command to parse /usr/bin/nm -B output from gcc object... f
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Tue, 7 Jan 2020 15:47:45 -0500
On 1/7/20, Martin Liška <address@hidden> 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
> 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 is defined as:
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