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

[Martin Liška]

On 1/7/20 10:07 PM, Bob Friesenhahn wrote:
> On Tue, 7 Jan 2020, 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:
>
> I don't know what vintage this documentation is (the copyright says it is from 2020 so it 
> seems to be the latest), but the page at 
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this about 
> "-fcommon"

Yes, this one is for current master and we always document option that is _NOT_ 
a default.
That's why you'll see documented -fno-common in GCC 9.2.0 manual:
https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Code-Gen-Options.html

Martin

> "The default is -fno-common, which specifies..."
>
> GCC 9.2 documentation says that the default is target dependent, which suggests 
> that some targets use no-common by default.
>
> > 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?
>
> Are there many users of dlpreopen()?
>
> > 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...
>
> LTO often causes strange issues.  It needs to be used with care.
>
> Thus far I have seen LTO reduce the output executable size (sometimes substantially if 
> there is a lot of "dead" code) but I have not seen a speed benefit to properly 
> written code.
>
> Bob