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

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 <[email protected]> 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