Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Bob Friesenhahn <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
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" "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 [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt