On 1/7/20, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Tue, 7 Jan 2020, Nick Bowler wrote: > >> On 1/7/20, Martin Liška <mli...@suse.cz> 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 think the fact that this test produces a common symbol most of the time, and that nm happens to work under LTO in this specific case, is mostly just a happy accident. >> 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()? I imagine there are users of -dlopen, which is supposed to automatically fall back to dlpreopen when shared library support is not available (for example, if the user configures the package with --disable-shared). Whether or not developers routinely test that their packages work with shared libraries disabled is another matter. Regardless, $global_symbol_pipe is part of the documented libtool interface, which says you can do: eval "$NM progname | $global_symbol_pipe" This is obviously busted because the failed configure test leads to global_symbol_pipe='' which will obviously cause problems in this usage (I just tested one of my scripts and yup, it is busted). But more importantly I suspect the actual busted feature is $global_symbol_to_cdecl, which is supposed to produce declarations for the symbols you get from global_symbol_pipe. This is clearly not working under LTO as it fails to distinguish functions and variables. It might be possible to detect this case in configure and come up with a symbol declaration that works for both functions and data, which might enable global_symbol_to_cdecl to generate working declarations, and would probably fix this configure test and typical usage scenarios like 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. When I last played around with LTO on my C code I was hoping to achieve reduced executable size but I found the results to be almost exactly the same as what I was already getting by compiling everything with -ffunction-sections -fdata-sections and then linking with -Wl,--gc-sections. And unlike LTO, those options don't break nm which would have required a massive amount of futzing with the build system to get things to even work. Cheers, Nick
