<p><br>
On May 7, 2013 10:27 AM, "Evgeniy Stepanov" <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
><br>
> This might be a bit late, but I've got another argument for bundling<br>
> zlib source with LLVM.<br>
><br>
> Sanitizer tools need to symbolize stack traces in the reports. We've<br>
> been using standalone symbolizer binary until now; sanitizer runtime<br>
> spawns a new process as soon as an error is found, and communicates<br>
> with it over a pipe. This is very cumbersome to deploy, because we<br>
> need to keep another binary around, specify a path to it at runtime,<br>
> etc. LLVM lit.cfg already carries some of this burden.<br>
><br>
> A much better solution would be to statically link symbolization code<br>
> into the user application, the same as sanitizer runtime library.<br>
> Unfortunately, symbolizer depends on several LLVM libraries, C++<br>
> runtime, zlib, etc. Statically linking all that stuff with user code<br>
> results in symbol name conflicts.<br>
><br>
> We've come up with what seems to be a perfect solution (thanks to a<br>
> Chandler's advice at the recent developer meeting). We build<br>
> everything down to (but not including) libc into LLVM bitcode. This<br>
> includes LLVMSupport, LLVMObject, LLVMDebugInfo, libc++, libc++abi,<br>
> zlib (!). Then we bundle it all together and internalize all<br>
> non-interface symbols: llvm-link && opt -internalize. Then compile<br>
> down to a single object file.<br>
><br>
> This results in a perfect isolation of symbolizer internals. One<br>
> drawback is that this requires source for all the things that I<br>
> mentioned - and at the moment we've got everything but zlib.<br>
><br>
> We'd like this to be a part of the normal LLVM build, but that<br>
> requires zlib source available somewhere. We could add a<br>
> cmake/configure option to point to an externally available source, but<br>
> that sounds like a complication we would like to avoid.<br>
><br>
> WDYT?<br>
><br>
><br>
> On Wed, Apr 17, 2013 at 5:02 PM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
> ><br>
> > On Wed, Apr 17, 2013 at 12:37 AM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
> >><br>
> >> On Apr 16, 2013, at 11:53 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> >> > Historically we've done the former. The latter would require Chris<br>
> >> > wanting to do that.<br>
> >><br>
> >> This case isn't so clearcut.  We like to include libraries in the source<br>
> >> to make it easy to get up and running without having to install a ton of<br>
> >> dependencies.  However, this has license implications and is generally<br>
> >> annoying.<br>
> ><br>
> ><br>
> > Looks like zlib license is good enough to avoid implications, but I can't<br>
> > really judge.<br>
> >><br>
> >><br>
> >> Given that zlib is so widely available by default, and that the compiler<br>
> >> can generate correct (albeit uncompressed) debug info, I think the best<br>
> >> thing is to *not* include a copy in llvm.  Just detect and use it if we can<br>
> >> find it, but otherwise generate uncompressed output.<br>
> ><br>
> ><br>
> > Sure, I'll go this way then. Thanks!<br>
> ><br>
> > --</p>
<p>It is possible to do both. Include an internal one and also link to and external one, and make it a compile time option which to use.</p>