On 16 Dec 2014, at 16:04, Dimitry Andric <d...@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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
