<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 2:30 AM, Will Newton <span dir="ltr"><<a href="mailto:will.newton@linaro.org" target="_blank">will.newton@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19 January 2015 at 21:30, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Mon, Jan 19, 2015 at 1:20 PM, Joerg Sonnenberger<br>
> <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
>><br>
>> On Mon, Jan 19, 2015 at 03:57:50PM -0500, Ed Maste wrote:<br>
>> > On 19 January 2015 at 11:32, Joerg Sonnenberger<br>
>> > <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
>> > > On Sun, Jan 18, 2015 at 10:28:27PM +0000, Davide Italiano wrote:<br>
>> > >> Some Makefiles on FreeBSD use -export-dynamic rather than<br>
>> > >> --export-dynamic.<br>
>> > >> We're gonna patch them in the FreeBSD tree, but as long as this is<br>
>> > >> supposed to be a drop-in replacement for GNU ld, I think supporting<br>
>> > >> single dash flag is fine.<br>
>> > ><br>
>> > > I dislike this for the overlap with the -e option.<br>
>> ><br>
>> > It is unfortunate, but necessary if we want to aim for full GNU ld<br>
>> > compatibility. Do we chase down various ld consumers and convince them<br>
>> > to switch to --?<br>
>><br>
>> I've seen existing bugs around -export-dynamic with typos and the like,<br>
>> so personally, I would prefer to handle it as error. In short: yes.<br>
><br>
><br>
> I think my preference is opposite. Trying to make an "improvement" over GNU<br>
> command line options would end up with a linker which is not fully<br>
> compatible with GNU. I think that would cause confusion. I want it to be a<br>
> drop-in replacement that just works.<br>
><br>
> If we really want to ban -export-dynamic, we should convince GNU to not<br>
> accept that option (or warn on that at least), maybe?<br>
<br>
</span>I believe it is worse than that - pretty much all the long options for<br>
GNU ld can be prefixed with '--' or '-' which makes option parsing<br>
really hairy, e.g. ld -library.<br>
<br>
For sanity requiring '--' for long options seems the better choice and<br>
indeed GNU ld only documents that style of long option but I don't<br>
think there is any prospect of GNU ld stopping parsing the '-' form of<br>
options.</blockquote></div><br>In the same way that there is likely no way for GNU ld to stop parsing the '-' forms, I suspect LLD will need to parse them in order to integrate with the huge amount of existing build scripts and systems.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We have certainly found time and again it was necessary to make Clang's commandline nearly *perfectly* match GCC's, even bug-for-bug in some cases.</div></div>