| Summary: | <sys-devel/binutils-2.34-r1: gc-nm does not report symbol types (was: app-crypt/p11-kit-0.23.20: ./libtool: eval: line 1720: syntax error near unexpected token `|') | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Craig Andrews <candrews> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | admnd, canarauc, candrews, cyshei, eugene.shalygin, herrtimson, kredba, sam, zlogene |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=706426 | ||
| Whiteboard: | wait for binutils-2.34-r1 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 618550, 712396, 713200, 714610 | ||
| Attachments: | build.log | ||
|
Description
Craig Andrews
2020-02-05 13:43:49 UTC
Created attachment 611770 [details]
build.log
your toolchain looks somehow broken to me (binutils). In the log it is seen you got: checking for BSD- or MS-compatible name lister (nm)... /usr/bin/gcc-nm while normally it should be: checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-pc-linux-gnu-nm -B the same for archiver, and ranlib (yes, I know these are symlinks). Could you pleaser test against stable binutils? I'm using ~amd64 binutils: [ebuild R ] sys-devel/binutils-2.34:2.34::gentoo USE="gold nls plugins -default-gold -doc -multitarget -static-libs -test" # ls -la /usr/bin/x86_64-pc-linux-gnu-nm /usr/bin/gcc-nm lrwxrwxrwx 1 root root 45 Jan 27 07:39 /usr/bin/gcc-nm -> /usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0/gcc-nm lrwxrwxrwx 1 root root 31 Feb 3 17:15 /usr/bin/x86_64-pc-linux-gnu-nm -> /usr/x86_64-pc-linux-gnu/bin/nm I'm not having trouble compiling any other packages (as far I'm aware, at least)... What other info can I provide to help? @toolchain, any idea? I do get different configure output using latest binutils than shown in the configure stage. oh wait, one more guess which also may "work". Could you please disable ccache? gcc-nm is fine to have if make.conf/package.env sets those explicitly. I don't see any details mentioned (what did fail so libtool got confused)? Let's see if I can find anything. Can you attach config.log meanwhile? The below is enough to trigger the same failure for me: app-crypt/p11-kit $ CFLAGS="-O2 -flto" LDFLAGS="-Wl,-O1 -Wl,--as-needed -flto -Wl,--hash-style=gnu" ebuild p11-kit-0.23.20.ebuild clean compile Comparing config.log and build.log of 'CFLAGS="-O2 -flto"' and 'CFLAGS="-O2"' we can see the problem:
Good:
configure:6821: checking command to parse /usr/bin/x86_64-pc-linux-gnu-nm -B output from x86_64-pc-linux-gnu-gcc object
configure:6974: x86_64-pc-linux-gnu-gcc -c -O2 conftest.c >&5
configure:6977: $? = 0
configure:6981: /usr/bin/x86_64-pc-linux-gnu-nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm
configure:6984: $? = 0
configure:7050: x86_64-pc-linux-gnu-gcc -o conftest -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu conftest.c conftstm.o >&5
configure:7053: $? = 0
configure:7091: result: ok
Bad:
configure:6821: checking command to parse /usr/bin/x86_64-pc-linux-gnu-nm -B output from x86_64-pc-linux-gnu-gcc object
configure:6974: x86_64-pc-linux-gnu-gcc -c -O2 -flto conftest.c >&5
configure:6977: $? = 0
configure:6981: /usr/bin/x86_64-pc-linux-gnu-nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm
configure:6984: $? = 0
configure:7050: x86_64-pc-linux-gnu-gcc -o conftest -O2 -flto -Wl,-O1 -Wl,--as-needed -flto -Wl,--hash-style=gnu 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.
lto-wrapper: fatal error: /usr/bin/x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
configure:7053: $? = 1
configure:6974: x86_64-pc-linux-gnu-gcc -c -O2 -flto conftest.c >&5
configure:6977: $? = 0
configure:6981: /usr/bin/x86_64-pc-linux-gnu-nm -B conftest.o \| sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d' \> conftest.nm
configure:6984: $? = 0
cannot run sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d'
configure:7088: result: failed
This leads to two libtool variables left undefined:
Good:
lt_cv_sys_global_symbol_pipe='sed -n -e '\''s/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\'' | sed '\''/ __gnu_lto/d'\'''
lt_cv_sys_global_symbol_to_cdecl='sed -n -e '\''s/^T .* \(.*\)$/extern int \1();/p'\'' -e '\''s/^[ABCDGIRSTW][ABCDGIRSTW]* .* \(.*\)$/extern char \1;/p'\'''
Bad:
lt_cv_sys_global_symbol_pipe=
lt_cv_sys_global_symbol_to_cdecl=
That's why you see '| |' call without contents there: ./configure did not find a working 'nm' tool as configure test is broken.
'nm_test_var' comes from p11-kit-0.23.20/build/m4/libtool.m4's '_LT_CMD_GLOBAL_SYMBOLS' macro. It looks like mostly up-to-date http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4
You might want to extract minimal test and report it to libtool people.
My guess would be that you need to avoid reuse of 'nm_test_var' as function and variable at the same time in a single object.
At a glance libtool test tries to link together the following 2 files and indeed 'nm_test_var' has two conflicting declarations.
// file 1
#ifdef __cplusplus
extern "C" {
#endif
char nm_test_var;
void nm_test_func(void);
void nm_test_func(void){}
#ifdef __cplusplus
}
#endif
int main(){nm_test_var='a';nm_test_func();return(0);}
// file 2
/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests. */
#if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs. */
# define LT_DLSYM_CONST
#elif defined __osf__
/* This system does not cope well with relocations in const data. */
# define LT_DLSYM_CONST
#else
# define LT_DLSYM_CONST const
#endif
#ifdef __cplusplus
extern "C" {
#endif
extern int nm_test_func();
extern int nm_test_var();
/* The mapping between symbol names and symbols. */
LT_DLSYM_CONST struct {
const char *name;
void *address;
}
lt__PROGRAM__LTX_preloaded_symbols[] =
{
{ "@PROGRAM@", (void *) 0 },
{"nm_test_func", (void *) &nm_test_func},
{"nm_test_var", (void *) &nm_test_var},
{0, (void *) 0}
};
/* This works around a problem in FreeBSD linker */
#ifdef FREEBSD_WORKAROUND
static const void *lt_preloaded_setup() {
return lt__PROGRAM__LTX_preloaded_symbols;
}
#endif
#ifdef __cplusplus
}
#endif
Normally libtool known how to distinguish between code and data: lt_cv_sys_global_symbol_to_cdecl="sed -n"\ $lt_cdecl_hook\ " -e 's/^T .* \(.*\)$/extern int \1();/p'"\ " -e 's/^$symcode$symcode* .* \(.*\)$/extern char \1;/p'" Note: - T is translated to 'extern int foo()' - anything else is translated to 'extern char foo;' It's where -flto -fno-common suddenly has the difference: $ gcc -c a.c -o a.o -flto && gcc-nm a.o 00000000 T nm_test_func 00000000 C nm_test_var T/C: ok $ gcc -c a.c -o a.o && gcc-nm a.o 0000000000000000 T nm_test_func 0000000000000001 C nm_test_var T/C: ok $ gcc -c a.c -o a.o -flto && gcc-nm a.o 00000000 T nm_test_func 00000000 C nm_test_var T/C: ok $ gcc -c a.c -o a.o -fno-common && gcc-nm a.o 0000000000000000 T nm_test_func 0000000000000000 B nm_test_var T/B: ok $ gcc -c a.c -o a.o -fno-common -flto && gcc-nm a.o 00000000 T nm_test_func 00000000 T nm_test_var T/T: bad I think it's a gcc-nm bug. Filed upstream https://gcc.gnu.org/PR93609 It's a limitation in LTO API between gcc and binutils without a nice short workaround: https://sourceware.org/PR25355. Up to you how you want to handle it. The fix will be in binutils-2.35 With gcc-10 launched and in the portage tree, as lto user, what should I do ? The back-ported patch to 2.34 does not apply clean, or I am doing something wrong. For now, I am using binutils-9999, but it is not safe. (In reply to Cănărău Constantin from comment #14) > With gcc-10 launched and in the portage tree, as lto user, what should I do ? > The back-ported patch to 2.34 does not apply clean, or I am doing something > wrong. > For now, I am using binutils-9999, but it is not safe. I would say it's expected for system-wide LTO not to work in quite a few corner cases. As well as -O3. Using binutils-9999 sounds reasonable. We can also package binutils snapshot to get a better baseline for others. Or update binutils-2.34 to rebase against current 2.34 branch. https://gcc.gnu.org/PR93609#c5 notes there are fixes for this issue. I'm not sure how safe it is to use it given that it took a few iterations upstream to get it working. Unkeyworded binutils-2.34-r1 contains all the 2.34 branch fixes including this one: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=99fab1f056c44b2f568895262eaebc859319932c I didn't try it myself. You can try and check if it helps. I will start a full rebuild tomorrow with binutils-2.34-r1 and report back. I've emerged sys-devel/binutils-2.34-r1. I've confirmed that curl now emerges successfully, so bug 713200 is fixed. media-libs/libbluray also emerged, so bug 714610 is fixed too. I'll emerge a bunch of other random stuff too; if I experience any problems, I'll report back. Woohoo! Thanks for the test everyone! I did a full system rebuild. No problem regarding binutils encountered, just a few -fno-common issues. Thank you for your work! (In reply to Sergei Trofimovich from comment #19) > Woohoo! Thanks for the test everyone! Is it time to add keywords to binutils-2.34-r1 and make this issue resolved? (In reply to Craig Andrews from comment #21) > (In reply to Sergei Trofimovich from comment #19) > > Woohoo! Thanks for the test everyone! > > Is it time to add keywords to binutils-2.34-r1 and make this issue resolved? dilfridge@ planned to look at the testsuite failures this weekend before rekeywording. (In reply to Sergei Trofimovich from comment #22) > (In reply to Craig Andrews from comment #21) > > (In reply to Sergei Trofimovich from comment #19) > > > Woohoo! Thanks for the test everyone! > > > > Is it time to add keywords to binutils-2.34-r1 and make this issue resolved? > > dilfridge@ planned to look at the testsuite failures this weekend before > rekeywording. How's this going? (I'm really looking forward to this bug being closed :) ) What can we do to get keywords added to close this bug? Thanks again! (In reply to Craig Andrews from comment #24) > What can we do to get keywords added to close this bug? > > Thanks again! I believe it was already added in https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-devel/binutils/binutils-2.34-r1.ebuild?id=f57c6e8fd308d3a395848737c49d7619d4936438 |
