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

[Martin Liška]

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