http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46503
Summary: collect2's search for nm makes LTO support fragile
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Depends on: 46502
I've noticed that unlike the way as and ld are handled (where the versions used
at configure time are hard-coded), collect2 does a runtime search for a version
of nm to use. This makes LTO support quite fragile, causing LTO not to work
depending on the users' PATH.
This is related to PR lto/46502, where collect2 can only cope with GNU nm -n
output format. I've seen that if GNU nm happens to be in PATH, LTO works since
LTO markers are found in the object files, while it fails with Solaris nm -n,
which produces a completely different output format by default.
