[PATCH] D40558: [ELF] - Trigger error when -R <filename> is given.

[George Rimar via llvm-commits]

>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.
>
>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.

Two points from me:
"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"

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.
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).

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 ?

?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.

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171129/e24b2c8d/attachment.html>