<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 2:15 AM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">There are very good reasons why packaging an external library is a big headache in general.</div><div dir="ltr">However, for zlib it's not so bad for several reasons.</div><div dir="ltr"><br></div><div dir="ltr">1 zlib is stable, code and file format. The last release is 1.5 years old. Manually updating the zlib sources once or twice a  year is trivial.<br></div><div dir="ltr"><br></div><div dir="ltr">2 For llvm, there should not be a problem with possible security exploits forcing quick patch, as long zlib is used to encode debug information coming from llvm.</div><div dir="ltr"><br></div><div dir="ltr">3 gdb uses the system zlib library of which there are many outdated copies around, so gdb can not expect to have the latest zlib. Thus, even if we miss an update, it's not likely to be a real problem.</div></blockquote></div><br>Yes, these are all good points both against blindly bundling such libraries and why for LLVM + zlib they likely don't matter that much.</div></div>