<p dir="ltr">We can't patch bugs on the system libc of shipped devices, while with static linking, we can avoid all but the latest bugs in the toolchain (which I think the toolchain guys would be more receptive to fixing).</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">labath added a comment.<br>
<br>
In <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10887-23198526&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=MEqT8U_n7oNfuDW5NRbY3ZV384ZquXIYFPWmprwUdKM&m=oWGziMmqMC3C-dmlFwqp-LuzeQcIEOnx6avGaccuPbY&s=jqlgTSzxPTF7rctoUsYORnuHVJ14g9MYCQOP5G7ioWo&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10887#198526</a>, @chaoren wrote:<br>
<br>
> Using a shim results in about a 5M increase in the lldb-server binary<br>
>  because of the need to export all symbols dynamically. And still has those<br>
>  two bugs (which would be in the system libs, if linked dynamically).<br>
<br>
<br>
Couldn't this be avoided somehow (with some __attribute__ magic or something). In reality, we just need one symbol, "lldb_main", or such).<br>
<br>
And if that proves unfeasible and we have to statically link, I would prefer patching bugs in older libc over patching "features" in newer ones.<br>
<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10887&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=MEqT8U_n7oNfuDW5NRbY3ZV384ZquXIYFPWmprwUdKM&m=oWGziMmqMC3C-dmlFwqp-LuzeQcIEOnx6avGaccuPbY&s=15ff9-H4ifyYwHfVmz1URTOe_zC2YQZMVaLAR6JZ6aQ&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10887</a><br>
<br>
<br>
<br>
</div>