[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
Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Tue, 7 Jan 2020 16:40:15 -0500
On 1/7/20, Bob Friesenhahn <address@hidden> 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"
> "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
>> 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
> 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.