<div dir="ltr"><div><div>Your concerns definitely make sense from a developer perspective, but probably not as much from a user/admin perspective, and since I'm a user/admin of LLVM/clang and not familiar with its internals I don't have a good answer to your concerns.<br><br>But here's an explanation of where my desire for it to be a dynamic library is coming from.<br><a href="http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries" target="_blank">http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries</a><br>I have to say that I agree with all of the points in the Fedora guidlines as to why libraries shouldn't be linked statically (but as I said before I'm an LLVM/clang user/admin and not a developer). Also, Fedora/RHEL have a system called Software Collections ( <a href="https://fedorahosted.org/SoftwareCollections/">https://fedorahosted.org/SoftwareCollections/</a> ) for managing multiple versions of a library/application on the same machine, and they potentially help address your concerns but not without a little work.<br><br></div>Hopefully, that helps shed some light on my perspective.<br><br></div>Thanks,<br>Dave<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 4:35 AM, Laszlo Nagy <span dir="ltr"><<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>hi Dave,<br><br></div>for curiosity, if libclang*, libllvm* (the currently static artifacts) will be dynamic library, how would you solve these problems:<br><br></div>- install different versions of clang on the same machine? (developers do that)<br></div>- install a tool which is linked against an older version of libclang*? (tool developers might be/are in delay)<br><br></div>i know it is possible to do all of these with dynamic libraries. but i fear that it is less effort to use static libraries for clang developers and for tool developers. (playing with LD_LIBRARY_PATH or rpath is less preferred over static libraries.) so maybe a compiler is good exception from this packaging guideline rule. maybe creating a child package for compiler developers (containing the static libraries and the corresponding header files) could make it already more ecstatic. what do you think?<br><br></div><div>regards,<br></div><div>Laszlo<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Dec 4, 2014 at 4:31 AM, Dave Johansen <span dir="ltr"><<a href="mailto:davejohansen@gmail.com" target="_blank">davejohansen@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Dec 1, 2014 at 12:15 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would personally like to create a big DSO for all of clang, but I don't think anyone is working on this.</div></blockquote><div><br></div></span><div>How big of a project would this be? Basically, could someone like me that has no real experience working with LLVM/clang (other than building and using it) do this?<br></div><div>Thanks,<br>Dave<br></div></div></div></div>
<br></div></div><span>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></div>