<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 29, 2017 at 8:59 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>George Rimar <<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>> writes:<br>
<br>
>>I think we shouldn't even emit an error for the second case. -rpath is the information for the dynamic linker, and the static linker should blindly store given -rpath >paths to a file header, because the static linker doesn't know the actual runtime environment. It is a valid use case that a given -rpath is not a directory in a build >environment but a directory in a runtime environment.<br>
>><br>
>>Given that, I'm inclined to not to emit an error or a warning at all for -R and just make it an alias to -rpath. If you are so familiar with linker features that you want to >use --just-symbols, you are likely to know -R, -rpath and -just-symbols. -just-symbols is used very rarely, so in reality, I think this is not an issue.<br>
><br>
> Two points from me:<br>
> "Given that, I'm inclined to not to emit an error or a warning at all for -R and just make it an alias to -rpath. If you are so familiar with linker features that you want to use --just-symbols, you are likely to know -R"<br>
><br>
> Last part means that we should implement -R both for -rpath and --just-symbols, like original GNU linkers do. As it is what is expected by user, who familar with both.<br>
> Currently our behavior always behaves as -rpath without warnings or errors and produce broken output. And that nehavior is definetely not expected (and comments for PR35067 shows that).<br>
><br>
> And then making -R an alias for one of these options is just not correct. If it's intention is to share 2 different behaviors it should be separate option with corresponding description, no ?<br>
><br>
</span>> ?Currently no our tests use -R for -rpath. What about if we drop supporting -R completely ? We can show a error suggesting to use explicitly use -rpath/--just-symbols instead.<br>
<br>
I *think* that using -R for --rpath is fairly common.<br>
<br>
I think I am back to favoring -R being an alias for rpath and producing<br>
an error for "--rpath file" or "-R file". Yes, the build machine might<br>
have a file and the intended run environment a directory, but that seems<br>
unlikely and easy to avoid.<br></blockquote><div><br></div><div>I'm not in favor of that. Reasons being that (1) assuming that a runtime environment is the same as a build environment is generally a bad idea even though it can be easily avoided, (2) --just-symbols is used very rarely, and (3) the -R option's behavior is undeniably a bit too hacky. Now seems like a good time to kill that tricky behavior.</div></div></div></div>