https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #5 from Nick Bowler <nbowler at draconx dot ca> ---
(In reply to Martin Liška from comment #4)
> That's true, but it's only related to .o files (LTO bytecode). If you link
> a final executable (or a shared library), you'll get proper type information:
>
> $ cat conftest.c
> int foo;
> int main() { return foo; }
> $ gcc conftest.c -flto -fno-common
> $ nm a.out | grep ' main'
> 00000000004010f2 T main
> $ nm a.out | grep foo
> 000000000040402c b foo
>
> Would it be possible to libtool to make the detection on a binary executable
> or a shared library?
Probably not. The features being probed, by their very nature, generally
need to be used prior to linking.
The configure test is actually working essentially correctly. Libtool
has determined that the feature being probed (the ability to produce
C declarations from nm output) will not work. This appears to be a
reasonably accurate assessment of the situation when using GNU nm
with LTO.
On the libtool side we can probably make the following improvements:
- The configure test actually links together the results for two
features (global_symbol_pipe and global_symbol_to_cdecl). So if
one doesn't work libtool assumes neither works. They could perhaps
be tested independently as I think global_symbol_pipe is probably
mostly OK in spite of this bug.
- The documentation should mention the possibility that these variables
could be empty on some targets if the feature is not supported.
- The export-symbols-regex feature should probably not fail gratuitously
on targets where global_symbol_pipe is not supported.
- Investigate alternate ways to implement global_symbol_to_cdecl on
GNU targets which avoids the LTO linking error.
- Investigate workarounds for this particular nm bug (e.g., libtool
could enable -ffat-lto-objects and using nm --plugin '' which restores
working nm behaviour).
--
You are receiving this mail because:
You are on the CC list for the bug.
