On 16 Dec 2014, at 17:15, David Chisnall <[email protected]> wrote: > > On 16 Dec 2014, at 16:04, Dimitry Andric <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
