[Top][All Lists]

[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: Martin Liška
Subject: Re: checking command to parse /usr/bin/nm -B output from gcc object... failed
Date: Wed, 8 Jan 2020 10:22:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

On 1/7/20 10:40 PM, Nick Bowler wrote:
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 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.

Well, the nm is using LTO plugin, so it should properly communicate
symbol types (in ideal world) :)

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

Yes, that's what I see for many package failures in openSUSE when I enable
-fno-common in optimization flags:

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.

I can provide quite some interesting numbers about usage of LTO (ideally with 

Or if you want to compare SPEC numbers:

In both scenarios LTO brings both speed up and size reduction.
And note that we enabled LTO in openSUSE Tumbleweed by default.



reply via email to

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