[LLVMdev] proposal to avoid zlib dependency.

Alex Rosenberg alexr at leftfield.org
Mon Sep 22 21:38:21 PDT 2014


On Sep 20, 2014, at 11:37 AM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Sat, Sep 20, 2014 at 11:26 AM, Dan Liew <dan at su-root.co.uk> wrote:
> On 18 September 2014 16:59, Reid Kleckner <rnk at google.com> wrote:
> > I also want to point out that there is prior art for bundling these types of
> > single-source-file utility libraries in lib/Support. We have MD5.cpp,
> > ConvertUTF.cpp, and reg*.c implementing various bits of functionality.
> > Adding a miniz.c doesn't seem like that big of a deal.
> 
> I should of taken a look at miniz first! It is pretty small. I guess provided
> 
> 1.The library code is properly namespaced to prevent symbol clashes
> for LLVM clients that already use miniz directly or indirectly.
> 2. Someone takes ownership over this code inside LLVM
> 
> then this is probably fine. Sorry I have a bit of knee-jerk reaction
> where I hear about embedding libraries because it's caused me problems
> in the past.
> 
> Would the aim be to use miniz as a fallback if libz isn't available or
> we want always use miniz?
> 
> I'll submit the patch that started to be developed in this thread to
> llvm-commits for review anyway as it might be useful to have it in
> trunk.
> 
> I would much rather have consistent and predictable behavior by using the bundled source code on every platform.

Is your answer the same if we're talking about an asm version of zlib that's faster than the compiled version? Because that's a thing.

-----------------------------------------
Alex Rosenberg
Manager, Platform Architecture
Sony Computer Entertainment America, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140922/15eff504/attachment.html>


More information about the llvm-dev mailing list