|
From: | Martin Liška |
Subject: | Re: checking command to parse /usr/bin/nm -B output from gcc object... failed |
Date: | Wed, 8 Jan 2020 15:08:07 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 |
On 1/8/20 10:16 AM, Martin Liška wrote:
On 1/7/20 9:47 PM, 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: configure:6307: checking command to parse /usr/bin/nm -B output from gcc object[...]configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -fno-common -flto conftest.c conftstm.o >&5 conftest.c:18:12: error: variable 'nm_test_var' redeclared as function 18 | extern int nm_test_var(); | ^ conftest.c:4:6: note: previously declared here 4 | relocations are performed -- see ld's documentation on pseudo-relocs. */ | ^ lto1: fatal error: errors during merging of translation units compilation terminated. As seen, I bet problem is in conftstm.o file (for which I can't see how it's created). Probably the file is missing declaration of nm_test_var and so that it's implicitly deduced to be int nm_test_var().nm_test_var is defined as: char nm_test_var; The test works by running nm on this file, parsing the output, and then generating a C file which inserts references to all the exported symbols it finds. Then this is linked with the original file. With a "normal" compiler and -fno-common nm_test_var goes in BSS and will be marked "B" in the nm output.Hello.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 issue for that: https://sourceware.org/bugzilla/show_bug.cgi?id=25355
So apparently it's a known limitation of the LTO plugin. Question is whether we can somehow workaround that? Martin
That will fix the problem, so let's see. Thanks, MartinSo it is indistinguishable from functions and when the C file is generated, a function declaration for nm_test_var is emitted (if it was correctly marked "B", then a variable declaration will be emitted). It's really unfortunate that LTO breaks nm in this way. But even if this configure test didn't fail I suspect subsequent users of $global_symbol_pipe will expect nm to work properly and it won't. 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? 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... Cheers, Nick
[Prev in Thread] | Current Thread | [Next in Thread] |