[Top][All Lists]

[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

From: Martin Liška
Subject: Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Date: Wed, 8 Jan 2020 15:08:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

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

   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.

Thank you for identification of the root cause. I've just created a nm issue
for that:

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


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


 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]