[llvm-dev] Linker Option support for ELF

[James Y Knight via llvm-dev]

On Fri, Jan 12, 2018 at 8:11 PM, Cary Coutant <ccoutant at gmail.com> wrote:

> > But I'm very much against allowing any sort of option that specifies full
> > paths to be embedded, including "-L". Typically, object files are
> > location-independent -- if you want to copy them to another system and
> run
> > the linker there (with an appropriate sysroot path), that's going to work
> > perfectly fine. But as soon as you start allowing path options to be
> > embedded, you're in a whole new world, with a whole new set of possible
> > pain. And, AFAICT, other systems do not allow that, either.
>
> While this is true in some development environments, in others, the
> ability to embed a path can be very useful. It's common to have
> third-party libraries installed in locations that aren't in the
> default search path, but installed in the same location on each build
> machine.



We already do the same for dynamic linking with RPATH,


Even if it may be potentially useful in some circumstance, I'd argue it's
not nearly worth it.

If your library is located in a nonstandard location, it seems likely that
its headers are also likely located in a nonstandard location, so you need
-I to find the headers anyhow, in many cases. Also providing -L to find the
lib does not seem a big problem. Sure, there could be a case where you
don't need the headers from the other lib to compile your source, only an
indirect dependency on it from a precompiled .o file.

And, yes, shared-libs can certainly have an RPATH embedded in them. And
that has downsides, and correspondingly, tooling (e.g. chrpath, patchelf)
to help ameliorate them. But, the advantage there (being able to run a
binary without setting environment variables) seems much greater.

which reminds
> me that we'll probably want to support an "rpath" option as well


Please no to that, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180112/c381007b/attachment-0001.html>