Using the following example C file: int foo; int bar = 0; And compiling the file normally, with gcc -c -o test.o test.c, the nm output looks like this: 0000000000000000 B bar 0000000000000004 C foo And with gcc -fno-common -c -o test.o test.c: 0000000000000004 B bar 0000000000000000 B foo But when compiling with lto, and using the linker plugin with nm, it returns incorrect symbol types: With gcc -flto -c -o test.o test.c: 00000000 T bar 00000000 C foo With gcc -flto -fno-common -c -o test.o test.c: 00000000 T bar 00000000 T foo In both cases, it's reporting the symbols as being in the text (code) section. This behaviour confuses the libtool configure-time check used by the global_symbol_pipe feature (causing linking errors when compiling packages that use the libtool -export-symbols-regex feature in combination with gcc -flto, particularly when also using -fno-common) Link to thread about the libtool issue: https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html I'm guessing that this is probably due to a limitation of how nm is using the linker plugin interface? The symbols that the plugin reports using the ld_plugin_add_symbols linker interface method don't include section information. I'm currently using: gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1) Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU nm version 2.32-30.fc31 Copyright (C) 2019 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty.
Oops, missed that this had already been filed. *** This bug has been marked as a duplicate of bug 25355 ***