[PATCH] D84029: [clang][Driver] Default to /usr/bin/ld on Solaris

Fri Jul 31 05:07:20 PDT 2020

ro added a comment.

In D84029#2170105 <https://reviews.llvm.org/D84029#2170105>, @MaskRay wrote:

> Can you add a test to `test/Driver/solaris-ld.c`?

No, this needs a separate testcase: the `-C` option unconditionally passed to the linker is only understood by the native `ld`.

I've added `solaris-ld-sld.c` instead, and also need a `system-solaris` feature to restrict it.  Since `/usr/gnu/bin/ld` isn't necessarily installed, there should be a way to mark the test `UNSUPPORTED` if it's missing.  I couldn't find how to do so, though.

Tested on `amd64-pc-solaris2.11` (`FAIL`s without the patch, `PASS`es with it) and `x86_64-pc-linux-gnu` (comes up `UNSUPPORTED`).

>> However, if someone forgets this, it depends on the user's PATH whether or not clang finds the correct linker, which doesn't make for a good user experience.
>
> Not very sure about this. The last resort of GetProgramPath is `PATH`. On FreeBSD and Linux, this is how `/usr/bin/ld` gets selected. PATH can affect `ld` choice.

True, but all possible linkers strive to be GNU `ld` compatible on those systems.  OTOH, on proprietary systems (Solaris, HP-UX, AIX, previsously IRIX, Tru64 UNIX) there was a native linker years if not decades before GNU `ld` started. Sometimes `gld` has added some options for compatibility with the native linker, sometimes native linkers (like the Solaris one later in the Solaris 11 cycle) added some options for `gld` compatiblity.

However, they usually have different options apart from the very basic ones (`-L`, `-l`, `-o`) and one needs to select the right one to avoid mismatches. Alternatively, one could  detect the linker flavour at runtime and adapt accordingly.  However, the native linkers are usually more featureful/better integrated with the system and thus the primary choice.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84029/new/

https://reviews.llvm.org/D84029