libtool
[Top][All Lists]
Advanced

[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: Bob Friesenhahn
Subject: Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Date: Tue, 7 Jan 2020 15:07:05 -0600 (CST)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

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"

"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
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

reply via email to

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