Migration to dynamic libs for llvm and clang

[Dimitry Andric]

On 16 Dec 2014, at 16:58, David Chisnall <theraven at FreeBSD.org> wrote:
> On 16 Dec 2014, at 15:46, Ed Maste <emaste at freebsd.org> wrote:
>> One of goals for the toolchain prior to the FreeBSD 11 branch is to
>> create a libllvm.so and libclang.so for use by all of the LLVM family
>> tools installed in the base system. This message is just a heads-up in
>> case anyone has questions or comments on the idea.
>> 
>> We currently build a large number of static libs for the llvm and
>> clang components, which are reused in a number of tools in the LLVM
>> family. The resulting binaries end up quite large, and as a group
>> require a lot of disk space. For example, LLDB includes a copy of
>> Clang, used as its expression parser.  As a result, on my desktop
>> /usr/bin/clang and /usr/bin/lldb are both 27MB.
>> 
>> Over time we may add additional LLVM family tools (e.g.,
>> llvm-objdump), and this will help avoid excessive bloat as we do so.
>> 
>> I expect libllvm.so and libclang.so will go in /usr/lib/private.
> Hi Ed,
> 
> Please can we have a name other than libclang, to avoid name collisions and confusion with, uh, libclang?  libcfe maybe?

This is precisely why the libs should go into /usr/lib/private, so as to
avoid collisions with any upstream libraries installed by e.g. ports (or
when you manually run "make install" after building).

I'm not sure we want to go the 'libbsdfoo.so' route again, as Baptiste
tried this before, and seems to have reversed it again. :)

That said, I agree with the general idea, but one of the first things
we should decide is whether this will be optional or not.  Having to
maintain yet another WITH_CLANG_FOO option is burdensome...

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20141216/3ecf33c4/attachment.sig>