llvm dev - Sep 2014 - [LLVMdev] proposal to avoid zlib dependency.

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>

On Thu, Sep 18, 2014 at 2:15 AM, Yaron Keren <yaron.keren at gmail.com>
wrote:
> 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.
>
Yes, these are all good points both against blindly bundling such libraries
and why for LLVM + zlib they likely don't matter that much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/e1cf73dd/attachment.html>

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.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chandler Carruth
Sent: Thursday, September 18, 2014 11:18
To: Yaron Keren
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] proposal to avoid zlib dependency.


On Thu, Sep 18, 2014 at 2:15 AM, Yaron Keren <yaron.keren at
gmail.com<mailto:yaron.keren at gmail.com>> wrote:
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.

Yes, these are all good points both against blindly bundling such libraries and
why for LLVM + zlib they likely don't matter that much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/c992cfbc/attachment.html>