On Tue, 2008-05-13 at 21:03 -0500, Owen Anderson wrote:> On May 13, 2008, at 6:38 PM, Óscar Fuentes wrote: > > Last time I checked, building LLVM on Windows (MinGW or MSVC) did not > > produce dlls. > > > > Has this changed? > > > > I was succesful converting the libraries produced by MinGW to dlls, > > though. > > > > It's a little bit immaterial whether they're shared or static > libraries, since one would be distributing them bundled with your > compiler anyways.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. shap
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 -------------- 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/33d33a74/attachment.bin>
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