[llvm-bugs] [Bug 42503] New: -fuse-ld on unknown triple uses gcc instead of gnutools

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42503

            Bug ID: 42503
           Summary: -fuse-ld on unknown triple uses gcc instead of
                    gnutools
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: drdeeglaze at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Not sure if feature request or bug, but..

I'm switching our GCC-based toolchain for the Asylo project (https://asylo.dev)
over to clang, and have been trying to avoid modifying clang in the process.

Asylo is kind of link a different OS from existing OSes, but is POSIX-based, so
very similar to Linux. Our current backends target x86_64, so I've chosen the
target triple x86_64-newlib-asylo-gnu.

Since asylo is an unknown OS, the toolchain defaults to Generic_GCC. Everything
compiles just fine with clang, but the linker fails trying to run gcc to
complete the link command. I pass in -fuse-ld=lld, but this is not relevant to
the command issued in ToolChains/Gnu.cpp.

If providing -fuse-ld were to drive gnutools::Linker-like behavior, would that
be a dramatic semantic change, or would it be a reasonable improvement? At this
point, I have a tiny Asylo subclass of Generic_GCC that does nothing but return
a gnutools::Linker for buildLinker in order to make local progress. This feels
too heavy-handed for just choosing a linker without a gcc fallback though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190704/3716d366/attachment.html>