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

[Nick Bowler]

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
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