[Bug lto/46503] New: collect2's search for nm makes LTO support fragile
ro at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Nov 16 16:37:00 GMT 2010
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: unassigned@gcc.gnu.org
ReportedBy: ro@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.
More information about the Gcc-bugs
mailing list