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. On Thu, Sep 18, 2014 at 3:03 AM, Chandler Carruth <chandlerc at google.com> wrote:> > On Thu, Sep 18, 2014 at 2:58 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > >> There is still one reason this should NOT be done: >> >> >> >> If some other library which uses LLVM wants to use zlib (either the >> system version or one built by hand) we will have linker issues with >> multiple definition, as LLVM only works with static libraries on Windows. >> Unless LLVM uses a custom prefix for its internal ZLib, which would “only” >> lead to more binary bloat. >> > > If we do this at all, we would clearly have to use an LLVM-specific name > for any functions / routines / etc. > > While this might be extraneous space in the binary, compared to even the > smallest part of LLVM, I suspect it would be lost in the noise. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/dc200a7c/attachment.html>
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.
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/efeb3a52/attachment.html>
Am 20.09.2014 20:26, schrieb Dan Liew:> 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 >is miniz 100% zlib compatible? or is that not a need i've tested miniz against zlib 2.7 month ago and miniz wasn't always equaly able to decompress given data like zlib was maybe i can recheck my application with current miniz