|
From: | Roumen Petrov |
Subject: | Re: checking command to parse /usr/bin/nm -B output from gcc object... failed |
Date: | Sat, 11 Jan 2020 21:20:16 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5 |
Martin Liška wrote:
It is clear that defect 25355 never will be fixed - by design plugin architecture is not suitable for lto and nobody would like to work on new version ( LD_PLUGIN_API_VERSION 2? ).[SNIP]However, LTO breaks nm really badly and with -fno-common this variable gets marked as "T" in the nm output.Thank you for identification of the root cause. I've just created a nm issuefor that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355
So apparently it's a known limitation of the LTO plugin. Question is whetherwe can somehow workaround that?
Work-around was already provided - please see following feedback : https://lists.gnu.org/archive/html/libtool/2020-01/msg00027.html
Let me quote Nick Bowler feedback: ======================== Workaround: add -ffat-lto-objects to CFLAGS so you get proper symbol tables in object files and then set NM='nm --plugin ""' to completely disable the busted LTO support in nm. For example: ./configure CFLAGS='-flto -fno-common -ffat-lto-objects' NM='nm --plugin ""' ========================
Martin
[SNIP]
[Prev in Thread] | Current Thread | [Next in Thread] |