[LLVMdev] proposal to avoid zlib dependency.

[Chandler Carruth]

On Thu, Sep 18, 2014 at 8:23 AM, Filip Pizlo <fpizlo at apple.com> wrote:

> I tend to think that bundling is ugly because it makes it harder for a
> distributor or integrator to pick the exact versions of all of the
> components in the system.


I agree when the components might have other OS interactions, security
implications, etc. A good example is that we really need to use the system
termcap library (libtinfo.so or libcurses.so) because the system might have
implemented terminfo completely differently and expected software to Just
Work because it provides a compatible C interface that fits the spec.

But none of this seems to apply to zlib, MD5, or several other things. Here
we are actually trying to do compression or digesting to match the DWARF
spec (or some other spec, potentially even our own) and giving anyone the
freedom to influence how we do this doesn't actually seem good. For
example, if our implementation of the zlib interface happens to have bugs
in it, we actually need to keep those bugs in place to retain
compatibility. Using a fixed system library would be bad in this sense.


The other argument is one around maintenance which is a very relevant point
for any sizable (or numerous) dependencies (for example, bundling boost
seems like a bad idea), but seems moot for things as simple as compression
libraries or digesting libraries.


Finally, limiting our use of system libraries in the critical path of
compilation (emitting debug info is one of them) helps preserve our ability
to do LTO builds of Clang and other LLVM-based tools which are unimpeded in
their optimization. Every time they have to reach out to a system library,
the optimizer has to be much more conservative in LTO mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/0ba96c2d/attachment.html>