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

On 1/8/20 10:16 AM, Martin Liška wrote:
> 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

So apparently it's a known limitation of the LTO plugin. Question is whether
we can somehow workaround that?

Martin

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