Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 1/7/20 9:47 PM, Nick Bowler wrote:
> On 1/7/20, Martin Liška <[email protected]> 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.

Hello.

> 
> However, LTO breaks nm really badly and with -fno-common this variable
> gets marked as "T" in the nm output.

Thank you for identification of the root cause. I've just created a nm issue
for that:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355

That will fix the problem, so let's see.

Thanks,
Martin

>  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
>