| Summary: | sys-devel/libtool: nm detection fails when using LTO | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Paolo Pedroni <paolo.pedroni> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | galtgendo, gentoo |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=854666 https://bugs.gentoo.org/show_bug.cgi?id=854672 https://savannah.gnu.org/support/?108558 https://savannah.gnu.org/support/?108559 https://bugs.gentoo.org/show_bug.cgi?id=324107 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 618550 | ||
| Attachments: |
libindicator-12.10.1-r201:20150703-102346.log.gz
config.log |
||
|
Description
Paolo Pedroni
2015-07-03 10:33:14 UTC
...:roll ricers... Anyway, this and your other bug (553844) are most likely duplicates. This is most likely a variant of well known SystemRescueCD problem - libtool gets broken if $libpath is set. (In reply to Rafał Mużyło from comment #1) > ...:roll ricers... > > Anyway, this and your other bug (553844) are most likely duplicates. > > This is most likely a variant of well known SystemRescueCD problem - libtool > gets broken if $libpath is set. Too bad $libpath is unset on my system, then. Do you have something useful to add, or are you just trolling? (In reply to Paolo Pedroni from comment #2) > (In reply to Rafał Mużyło from comment #1) > > Anyway, this and your other bug (553844) are most likely duplicates. > > > > This is most likely a variant of well known SystemRescueCD problem - libtool > > gets broken if $libpath is set. > > Too bad $libpath is unset on my system, then. Do you have something useful > to add, or are you just trolling? Well, I'm trolling too, cause as of now, you deserve to be trolled. Regardless, the other potential cause for this problem is - duh - ricing, in this particular case a problem that the standard 'checking command to parse /usr/bin/nm -B output from x86_64-pc-linux-gnu-gcc object' test has with lto. You can check your config.log for the exact cause of the failure. Also, while this is more of configuration problem of this bugzilla, your attachment ended up twice compressed, so take care with that in the future. (In reply to Rafał Mużyło from comment #3) > Also, while this is more of configuration problem of this bugzilla, your > attachment ended up twice compressed, so take care with that in the future. That has nothing to do with the person attaching the file; it's a bug that occurs when downloading gzip attachments in Google Chrome. Please attach the environment file; this does seem like some variable is not being set correctly. *** Bug 553844 has been marked as a duplicate of this bug. *** (In reply to Mike Gilbert from comment #4) > (In reply to Rafał Mużyło from comment #3) > > Also, while this is more of configuration problem of this bugzilla, your > > attachment ended up twice compressed, so take care with that in the future. > > That has nothing to do with the person attaching the file; it's a bug that > occurs when downloading gzip attachments in Google Chrome. OK, I've been wondering about that for quite awhile. ...somewhat surprising... (In reply to Mike Gilbert from comment #5) > Please attach the environment file; this does seem like some variable is not > being set correctly. It's still config.log that holds the answer - that test should end with 'failed' as result. (In reply to Mike Gilbert from comment #5) > Please attach the environment file; this does seem like some variable is not > being set correctly. Thanks. I will do that ASAP. It is true, though, that if I disable lto, the compilation stage works fine (tests fail anyway, but I don't care about troubleshooting that, too). Created attachment 406244 [details]
config.log
:roll:
So, as I expected, a ricer error.
Throughout the config.log 'plugin needed to handle lto object' happens.
Never was really interested in lto before, but gcc manpage combined with a little googling says that with >=gcc 4.9.0 and >=binutils 2.25 you'll need at least a symlink from gcc lto plugin to binutils bfd-plugins dir (before 2.25 you needed to use gcc-{ar,nm,ranlib} wrappers - gcc called them for itself, but results of direct calls to the tools were as seen in this config.log).
(In reply to Rafał Mużyło from comment #10) Thanks for the info, between all the snark. ^_^ So would you call this a toolchain bug? (In reply to Mike Gilbert from comment #11) > (In reply to Rafał Mużyło from comment #10) > > Thanks for the info, between all the snark. ^_^ > > So would you call this a toolchain bug? Not really, more a case where certain quirks of autotools concepts combined with not explicit enough info on gcc manpage to produce a somewhat unfortunate result. However such symlink looks like one that should be managed by gcc-config, even if it only works only since binutils 2.25. Also only in gcc 4.9 -fno-fat-lto-objects became the default. On that note, won't gcc 5.1 transition be a bitch in Gentoo ? Those libstdc++ ABI changes look hard to detect properly, on the other hand 'revdep-rebuild -L libsdtc++.so.6'...yeah, wanna have an option B. Giving this to toolchain; re-assign if I got it wrong. I'm not sure I see this as a toolchain bug per se (other than the symlink to the lto plugin). The failures I've seen with -flto seem mostly to fall into 2 categories: undefined reference link failures (which could be easy-ish build/configure fixes) and optimization failures on certain "classes" of packages with hand-optimized code or special constructs (mostly graphics, audio, tools with lexer/parser generators, etc). This particular libtool failure crops up in several places, but would be a separate issue from the missing plugin symlink (plugin needed blah blah). The man page could certainly be more clear on a lot of things (-flto options being only one topic) but that doesn't mean a Gentoo doc can't straighten it out. I also wouldn't class this as a "ricer" issue, since we're not talking about crazy -O3 stuff (at least in my case) but things that should be "safe". So I see 3 issues here: 1) gcc-config fix 2) libtool/other fix 3) documentation fix Just my grumpy $.02 ... I believe this was fixed by now stable gcc-config-2.0:
https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=aab6bf7095a0ab921c78b07a202db207ce07a5f8
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6287d789783e493e625a06a548c4691851563d36 commit 6287d789783e493e625a06a548c4691851563d36 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-06 04:16:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-06 05:29:50 +0000 app-i18n/scim-m17n: re-run autoreconf to fix LTO The 2009 era distfile is so old that it probably has many bugs. We are particularly concerned by nm detection failing under LTO causing: ``` generating symbol list for `m17n.la' /usr/bin/nm -B .libs/m17n_la-scim_m17n_imengine.o | | /usr/bin/sed 's/.* //' | sort | uniq > .libs/m17n.exp ../libtool: 1: eval: Syntax error: "|" unexpected ``` Bug: https://bugs.gentoo.org/553842 Closes: https://bugs.gentoo.org/854666 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> app-i18n/scim-m17n/scim-m17n-0.2.3.ebuild | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) For completeness, libtool commits: commit 5911665520a53415bafd8bb6da9989b5fe25df80 Author: Peter Rosin <peda@lysator.liu.se> Date: Fri May 2 14:51:02 2014 +0200 libtool: prevent lto from stripping the magic cookie from the cwrapper Whole program optimization may remove unused symbols unless told they are really needed. Fixes sr #108559 reported by LRN. * build-aux/ltmain.in (func_emit_cwrapperexe_src:MAGIC_EXE): Try to ensure that the magic cookie is preserved. Signed-off-by: Peter Rosin <peda@lysator.liu.se> commit 13aa364c0c66f9f6b41f98772d0735039ac974a1 Author: Peter Rosin <peda@lysator.liu.se> Date: Tue May 6 10:11:34 2014 +0200 libtool: fix nm test for MSYS/MinGW The check for the -B option of nm does not work as intended on MSYS/MinGW. MSYS converts /dev/null to the DOW/Windows "equivanent" special file NUL, but the MinGW nm treats this file as any empty file. This means that you might end up with some fallback nm instead of the desired nm. This is not normally a problem, but if one nm is built without lto support, it starts to matter. Fixes sr #108558, reported by LRN. * m4/libtool.m4 (LT_PATH_NM) [MSYS]: Use a non-existant file instead of /dev/null when checking if nm supports -B. Signed-off-by: Peter Rosin <peda@lysator.liu.se> |
