Owen: Can you clarify what kinds of dynamic linker issues you are seeing? I speculate that cross-library dependency resolution is high on the list, but what else? shap On Tue, 2008-05-13 at 21:44 -0500, Owen Anderson wrote:> On May 13, 2008, at 9:22 PM, Jonathan S. Shapiro wrote: > > Owen: > > > > This is not correct. As the API stabilizes, it will become > > increasingly > > attractive to package LLVM as dynamic libraries. > > > > One consequence of continuous compilation is that there is a > > progressively larger body of tools that need to be "in on the joke" > > about compilation at various stages. This is particularly true about > > things like JIT engines, wherein every single process may need a > > completely redundant copy of the LLVM libraries. > > > > So if linkers choke on LLVM, we either need to submit upstream patches > > on those linkers or reconfigure the LLVM libraries so that things do > > not > > choke. > > > > We do in fact produce one shared library: libLTO, which contains the > parts necessary for implementing link-time optimization in a linker, > for just the reasons you pointed out above. ;-) > > --Owen > _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On May 13, 2008, at 10:12 PM, Jonathan S. Shapiro wrote:> Owen: > > Can you clarify what kinds of dynamic linker issues you are seeing? I > speculate that cross-library dependency resolution is high on the > list, > but what else? > > shapOthers could probably answer it better (this was before my time), but my understanding was that certain versions of certain dynamic linkers took a very long time to load the very large shared libraries that make up LLVM, resulting in application launch times on the order of minutes. The broader issue that LLVM is very large, and exposes an enormous API, because it is designed to serve many different purposes. This results in huge libraries with huge exported symbol sets, which can (in some cases) result in very poor dynamic linker performance. Most modern static linkers also support dead code stripping, so you don't end up paying too much of a space overhead in the final executable. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4260 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080513/7d3a73e3/attachment.bin>
Enabling the build of dynamic libraries in the makefiles (if that is not already done) would be helpful for development and testing purposes, if only so that people could start tracking these types of issues down... shap On Tue, 2008-05-13 at 22:34 -0500, Owen Anderson wrote:> On May 13, 2008, at 10:12 PM, Jonathan S. Shapiro wrote: > > > Owen: > > > > Can you clarify what kinds of dynamic linker issues you are seeing? I > > speculate that cross-library dependency resolution is high on the > > list, > > but what else? > > > > shap > > Others could probably answer it better (this was before my time), but > my understanding was that certain versions of certain dynamic linkers > took a very long time to load the very large shared libraries that > make up LLVM, resulting in application launch times on the order of > minutes. > > The broader issue that LLVM is very large, and exposes an enormous > API, because it is designed to serve many different purposes. This > results in huge libraries with huge exported symbol sets, which can > (in some cases) result in very poor dynamic linker performance. Most > modern static linkers also support dead code stripping, so you don't > end up paying too much of a space overhead in the final executable. > > --Owen > _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev