[Bug lto/46503] New: collect2's search for nm makes LTO support fragile

["ro at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.