Migration to dynamic libs for llvm and clang
David Chisnall
theraven at FreeBSD.org
Tue Dec 16 16:15:16 UTC 2014
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.
> 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.
David
More information about the freebsd-toolchain
mailing list