Mueller-Roemer, Johannes Sebastian
2014-Sep-18 09:58 UTC
[LLVMdev] proposal to avoid zlib dependency.
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>
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/fbe787e3/attachment.html>
Once LLVM is built and used as a dylib, we'd just mark the zlib symbols as hidden. :-) 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 don't know if this was mentioned already, but maybe we can have a compromise where a configure option can be used to select between the system zlib and whatever LLVM bundles. The default can be system zlib with an automatic fallback of using the bundled zlib (or zlib equivelant). -Filip> On 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/3d2e8be3/attachment.html>
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>