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>
Mueller-Roemer, Johannes Sebastian
2014-Sep-18 15:58 UTC
[LLVMdev] proposal to avoid zlib dependency.
Dylib/so/shared doesn't work on windows yet. ________________________________________ From: Filip Pizlo [fpizlo at apple.com] Sent: Thursday, September 18, 2014 5:23 PM To: Chandler Carruth Cc: Mueller-Roemer, Johannes Sebastian; LLVM Developers Mailing List Subject: Re: [LLVMdev] proposal to avoid zlib dependency. 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<mailto: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<mailto: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<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Sep 18, 2014 at 8:23 AM, Filip Pizlo <fpizlo at apple.com> wrote:> 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 agree when the components might have other OS interactions, security implications, etc. A good example is that we really need to use the system termcap library (libtinfo.so or libcurses.so) because the system might have implemented terminfo completely differently and expected software to Just Work because it provides a compatible C interface that fits the spec. But none of this seems to apply to zlib, MD5, or several other things. Here we are actually trying to do compression or digesting to match the DWARF spec (or some other spec, potentially even our own) and giving anyone the freedom to influence how we do this doesn't actually seem good. For example, if our implementation of the zlib interface happens to have bugs in it, we actually need to keep those bugs in place to retain compatibility. Using a fixed system library would be bad in this sense. The other argument is one around maintenance which is a very relevant point for any sizable (or numerous) dependencies (for example, bundling boost seems like a bad idea), but seems moot for things as simple as compression libraries or digesting libraries. Finally, limiting our use of system libraries in the critical path of compilation (emitting debug info is one of them) helps preserve our ability to do LTO builds of Clang and other LLVM-based tools which are unimpeded in their optimization. Every time they have to reach out to a system library, the optimizer has to be much more conservative in LTO mode. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/0ba96c2d/attachment.html>
> On Sep 20, 2014, at 11:42 AM, Chandler Carruth <chandlerc at google.com> wrote: > > > On Thu, Sep 18, 2014 at 8:23 AM, Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote: > 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 agree when the components might have other OS interactions, security implications, etc. A good example is that we really need to use the system termcap library (libtinfo.so or libcurses.so) because the system might have implemented terminfo completely differently and expected software to Just Work because it provides a compatible C interface that fits the spec. > > But none of this seems to apply to zlib, MD5, or several other things. Here we are actually trying to do compression or digesting to match the DWARF spec (or some other spec, potentially even our own) and giving anyone the freedom to influence how we do this doesn't actually seem good. For example, if our implementation of the zlib interface happens to have bugs in it, we actually need to keep those bugs in place to retain compatibility. Using a fixed system library would be bad in this sense.Has there ever been a zlib bug that caused a conformance issue for LLVM? -Filip> > > The other argument is one around maintenance which is a very relevant point for any sizable (or numerous) dependencies (for example, bundling boost seems like a bad idea), but seems moot for things as simple as compression libraries or digesting libraries. > > > Finally, limiting our use of system libraries in the critical path of compilation (emitting debug info is one of them) helps preserve our ability to do LTO builds of Clang and other LLVM-based tools which are unimpeded in their optimization. Every time they have to reach out to a system library, the optimizer has to be much more conservative in LTO mode.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140921/650f835d/attachment.html>