<div dir="ltr"><div dir="ltr">On Sun, Jul 25, 2021 at 12:15 AM Gilles Vollant <<a href="mailto:info@winimage.com">info@winimage.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 2021-07-24, Fangrui Song via llvm-dev wrote:<br>
<br>
> In gold, --wrap=log seems to apply to a non-default version symbol<br>
log@GLIBC_2.2.5 .<br>
> I consider it a bug.<br>
<br>
<br>
> Note: ld.lld's --wrap has another difference with GNU linkers<br>
> <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=26358" rel="noreferrer" target="_blank">https://sourceware.org/bugzilla/show_bug.cgi?id=26358</a><br>
> I personally think ld.lld's is superior because LTO, non-LTO and<br>
relocatable links behave the same.<br>
<br>
Do you known a difference in executable size and executable performance<br>
between -fuse-ld=lld ; -fuse-ld=bfd and -fuse-ld=gold for linking clang C++<br>
with lto objet and static library) ?<br>
<br>
</blockquote></div><br clear="all"><div>The linker just hands over the heavy lifting work to the llvm/lib/LTO library. There should be negligible performance/size difference.</div><div>Different linkers have different output section ordering and input section ordering. Different layouts may give different sizes but they are negligible.</div></div>