Migration to dynamic libs for llvm and clang

[Dimitry Andric]

On 16 Dec 2014, at 17:15, David Chisnall <theraven at FreeBSD.org> wrote:
> 
> On 16 Dec 2014, at 16:04, Dimitry Andric <dim at FreeBSD.org> wrote:
>> 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).
> 
> That's still potentially an issue if we add local tools that use libclang APIs (which we may well do).
> 
>> 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. :)
> 
> Upstream doesn't call it libclang (that's the name of the library with a stable C ABI, which is why I'd like us not to confuse it with something with a library with an unstable C++ API).  They do produce a libLLVM.so from the LLVM builds and work is underway to have shared library builds for clang.
> 
> libLLVM.so could potentially be in /usr/lib in 11 if we have a packaged base system, as it would allow us to have different .so versions installed if things demanded them.  The point releases guarantee backwards ABI compatibility, so we can still upgrade to them if required.

Unfortunately we already imported quite a lot of ABI-breaking bug fixes.
I would prefer only our own tools to be linked against the "FreeBSD"
version of libllvm.so/libwhatever.so.


> 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...
> 
> I agree.  I'd quite like to see performance numbers for the compiler.  I think I saw about a 10% overhead for buildworld last time I tried, but that was a couple of years ago.

There is already a WITH_SHARED_TOOLCHAIN option, that defaults to off,
but I have had it on since approximately the time Kostik added it.  I
might just have gotten used to the overhead, if any...

I would like to do a bit of testing with that, but my TODO list is
rather full at this point, working on the 3.5.0 import. :)

-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/3ddee07f/attachment.sig>