<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 29, 2015 at 10:46 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D13244#255737" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13244#255737</a>, @ruiu wrote:<br>
<br>
> The GNU linker's behavior of trying to resolve all undefined symbols in DSOs looks broken in the first place. This is a linker and not a dynamic linker nor loader, it can just leave undefined symbols in DSO for the dynamic linker. LLVM itself, for example, always sets --allow-shlib-undefined to "[W]ork around a broken bfd ld behavior" (CMakeList.txt in the toplevel directory). In my opinion, we should just implement --allow-shlib-undefined behavior as default and ignore that option.<br>
<br>
<br>
</span>May be it is more reasonable to implement --allow-shlib-undefined behavior as default for both shared and executables but still allow to use ---no-allow-shlib-undefined if needed ?<br></blockquote><div><br></div><div>I doubt that we would want --no-allow-shlib-undefined, but even if we do, that's probably too detailed that we don't actually need to take care of it at this stage of development.</div></div></div></div>