<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 1:07 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><p dir="ltr">.<br>
><br>
> I wouldn't mind if the default simply stayed "false", like it was in the past for everything but those tools that can know it's safe. But, if there's going to be any a default of using the new relocs in other circumstances, I think that must be guarded behind the off-by-default cmake flag, for now. Even for the developer tools. Probably in a couple years from now it'll be safe to change the global default without breaking anything, but it's really not, now...</p>
</span><p dir="ltr">If we don't change the default in the library, tool writers are not likely to find out that there are new relocations out there and we will be having exactly the same discussion a couple of years from now.</p>
<p dir="ltr">If we change the library default each tool will find out about it when they upgrade, trivially disable  it and in the future we will be able to check if anyone is still depending on it.</p>
<p dir="ltr"></p></blockquote><div>There are a number of tools that use llvm's MC layer to produce object files. Almost all such tools that produce object files are completely unrelated to linkers, and don't care what the produced object file looks like -- except that it works. They don't themselves depend on having, or not having, the new relocation types. The ONLY thing that matters is that the linker that will be used (typically the system linker) will be able to consume it.</div><div><br></div><div>We should not be forcing every such tool to individually discover that we chose a broken-for-many-users default and work around it. These people cannot fix the problem -- there is no action that needs to be taken, other than waiting.</div><div><br></div><div>If we wait for two years before enabling this by default, the situation will quite certainly be quite different: the number of users who have system linkers that don't support the new relocation types will be much lower, as they will have upgraded to a new version which does support it.</div></div></div></div>