<div dir="ltr"><div>On Fri, Jan 12, 2018 at 8:11 PM, Cary Coutant <span dir="ltr"><<a href="mailto:ccoutant@gmail.com" target="_blank">ccoutant@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> But I'm very much against allowing any sort of option that specifies full<br>
> paths to be embedded, including "-L". Typically, object files are<br>
> location-independent -- if you want to copy them to another system and run<br>
> the linker there (with an appropriate sysroot path), that's going to work<br>
> perfectly fine. But as soon as you start allowing path options to be<br>
> embedded, you're in a whole new world, with a whole new set of possible<br>
> pain. And, AFAICT, other systems do not allow that, either.<br>
<br>
</span>While this is true in some development environments, in others, the<br>
ability to embed a path can be very useful. It's common to have<br>
third-party libraries installed in locations that aren't in the<br>
default search path, but installed in the same location on each build<br>
machine. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">We already do the same for dynamic linking with RPATH,<span> </span></span></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Even if it may be potentially useful in some circumstance, I'd argue it's not nearly worth it.</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">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.<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">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 (<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">being able to run a binary without setting environment variables)</span> seems much greater.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">which reminds<br>
me that we'll probably want to support an "rpath" option as well</blockquote><div><br></div><div>Please no to that, too.</div><div><br></div></div></div></div>