On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <bob.wilson at apple.com> wrote:> If you build with configure+make, just run configure with —disable-zlib. > We do this routinely, so I’m pretty sure it works. >It "works" as in it builds. However, the support for it is disabled since zlib::compress will always return StatusUnsupported, so the debug information will just not be compressed. Effectively, compressed DWARF is unsupported on Windows.> On Sep 16, 2014, at 3:42 PM, Reid Kleckner <rnk at google.com> wrote: > > It might not be available, so all codepaths have to recover from zlib > unavailability. For example, I don't think compressed DWARF works on > Windows. > > On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <fpizlo at apple.com> wrote: > >> What is the downside of Zlib dependency? I'm curious! :-) >> >> -Filip >> >> On Sep 16, 2014, at 2:45 PM, Christophe Duvernois < >> christophe.duvernois at gmail.com> wrote: >> >> Hi >> >> Miniz (https://code.google.com/p/miniz/ ) is very small and performant >> implementation of zlib compression with api compatibility and it is public >> domain... >> Miniz can be integrated directly into the llvm source code. >> So it could be a good replacement or alternative to avoid zlib >> dependency... >> >> If someone is interested i can provide a patch. >> >> Regards >> Christophe >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/85fcc53a/attachment.html>
Saleem Abdulrasool <compnerd at compnerd.org> writes:> On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: > >> If you build with configure+make, just run configure with —disable-zlib. >> We do this routinely, so I’m pretty sure it works. >> > > It "works" as in it builds. However, the support for it is disabled since > zlib::compress will always return StatusUnsupported, so the debug > information will just not be compressed. Effectively, compressed DWARF is > unsupported on Windows.IIUC zlib availability is tested and the library used if present. Do you mean that LLVM does not use zlib on Windows when the library is present?
On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> IIUC zlib availability is tested and the library used if present. Do you > mean that LLVM does not use zlib on Windows when the library is present?Sure, but if there aren't instructions for how to do it easily, then it's effectively unsupported. There isn't really a canonical way to "install" headers and libraries on Windows like you would on Linux. It probably works on MinGW, but then you're a MinGW binary in a MinGW world. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/78ced205/attachment.html>
FWIW, I strongly support finding a fully license-compatible way to just implement zlib-compatible compression with no external library dependencies. There are a myriad of reasons, some already raised: - Means that functionality isn't universally available, for example, on Windows - Means that we have to debug performance problems or other issues with different source code depending on the nature of specific libraries used If the cost is low (and it seems low for miniz or zlib or whatever) why go through the hassle of using a system library.... On Tue, Sep 16, 2014 at 7:11 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote:> On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: > >> If you build with configure+make, just run configure with —disable-zlib. >> We do this routinely, so I’m pretty sure it works. >> > > It "works" as in it builds. However, the support for it is disabled since > zlib::compress will always return StatusUnsupported, so the debug > information will just not be compressed. Effectively, compressed DWARF is > unsupported on Windows. > > >> On Sep 16, 2014, at 3:42 PM, Reid Kleckner <rnk at google.com> wrote: >> >> It might not be available, so all codepaths have to recover from zlib >> unavailability. For example, I don't think compressed DWARF works on >> Windows. >> >> On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <fpizlo at apple.com> wrote: >> >>> What is the downside of Zlib dependency? I'm curious! :-) >>> >>> -Filip >>> >>> On Sep 16, 2014, at 2:45 PM, Christophe Duvernois < >>> christophe.duvernois at gmail.com> wrote: >>> >>> Hi >>> >>> Miniz (https://code.google.com/p/miniz/ ) is very small and performant >>> implementation of zlib compression with api compatibility and it is public >>> domain... >>> Miniz can be integrated directly into the llvm source code. >>> So it could be a good replacement or alternative to avoid zlib >>> dependency... >>> >>> If someone is interested i can provide a patch. >>> >>> Regards >>> Christophe >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > _______________________________________________ > 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/ec061b51/attachment.html>
Hi, There are very good reasons why packaging an external library is a big headache in general. However, for zlib it's not so bad for several reasons. 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. 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. 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. Yaron 2014-09-18 10:48 GMT+03:00 Chandler Carruth <chandlerc at google.com>:> FWIW, I strongly support finding a fully license-compatible way to just > implement zlib-compatible compression with no external library dependencies. > > There are a myriad of reasons, some already raised: > > - Means that functionality isn't universally available, for example, on > Windows > - Means that we have to debug performance problems or other issues with > different source code depending on the nature of specific libraries used > > If the cost is low (and it seems low for miniz or zlib or whatever) why go > through the hassle of using a system library.... > > On Tue, Sep 16, 2014 at 7:11 PM, Saleem Abdulrasool <compnerd at compnerd.org > > wrote: > >> On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> If you build with configure+make, just run configure with --disable-zlib. >>> We do this routinely, so I'm pretty sure it works. >>> >> >> It "works" as in it builds. However, the support for it is disabled >> since zlib::compress will always return StatusUnsupported, so the debug >> information will just not be compressed. Effectively, compressed DWARF is >> unsupported on Windows. >> >> >>> On Sep 16, 2014, at 3:42 PM, Reid Kleckner <rnk at google.com> wrote: >>> >>> It might not be available, so all codepaths have to recover from zlib >>> unavailability. For example, I don't think compressed DWARF works on >>> Windows. >>> >>> On Tue, Sep 16, 2014 at 3:21 PM, Filip Pizlo <fpizlo at apple.com> wrote: >>> >>>> What is the downside of Zlib dependency? I'm curious! :-) >>>> >>>> -Filip >>>> >>>> On Sep 16, 2014, at 2:45 PM, Christophe Duvernois < >>>> christophe.duvernois at gmail.com> wrote: >>>> >>>> Hi >>>> >>>> Miniz (https://code.google.com/p/miniz/ ) is very small and performant >>>> implementation of zlib compression with api compatibility and it is public >>>> domain... >>>> Miniz can be integrated directly into the llvm source code. >>>> So it could be a good replacement or alternative to avoid zlib >>>> dependency... >>>> >>>> If someone is interested i can provide a patch. >>>> >>>> Regards >>>> Christophe >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >> >> >> -- >> Saleem Abdulrasool >> compnerd (at) compnerd (dot) org >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > 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/79765526/attachment.html>
Possibly Parallel Threads
- [LLVMdev] proposal to avoid zlib dependency.
- [LLVMdev] proposal to avoid zlib dependency.
- [LLVMdev] proposal to avoid zlib dependency.
- [LLVMdev] proposal to avoid zlib dependency.
- [LLVMdev] [RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf