Date: Tue, 16 Dec 2014 10:39:32 -0700 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: Migration to dynamic libs for llvm and clang Message-ID: <4E3A3DA8-209C-43E1-83D4-928823CCBF04@bsdimp.com> In-Reply-To: <F44F2112-59A7-4351-BEED-AB1B17BDA0C4@FreeBSD.org> References: <CAPyFy2DeLiFAW_yS14r1n89r92MFG1sbX88rNgaJshwH9-%2BkQg@mail.gmail.com> <41F09A1C-01D6-42C9-B495-244DFC2B0364@FreeBSD.org> <D359161D-B14C-4F19-8F0D-57FE530D0AF4@FreeBSD.org> <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@FreeBSD.org> <F44F2112-59A7-4351-BEED-AB1B17BDA0C4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Dec 16, 2014, at 9:32 AM, Dimitry Andric <dim@FreeBSD.org> wrote: > > On 16 Dec 2014, at 17:15, David Chisnall <theraven@FreeBSD.org> wrote: >> >> On 16 Dec 2014, at 16:04, Dimitry Andric <dim@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… The 10% figure has been relatively constant over the lifetime of shared libraries in FreeBSD. This is the average hit of using shared libraries and everybody accepts that. I doubt time has changed this much at all. > 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. :) We should defer testing until after that import :) Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkG5VAAoJEGwc0Sh9sBEA9zQQAKA078Sc8X2VT+C6B7YaLBLT uoYXq66Mg6rSN5QU2dJvKMiak7vgYHBEbi4RvjXGPq+TvC9z74AXeQpn1uwLCfUZ T425jHcihhyguq8/Jk9U7KEnB5zBvb3iyIRfpKJUOt2YVHhKzGkruKmOhm2KgoOm v+/hPHnZJh30nJQldywBpQyrz4RC3zhFM6rn9D9S8LthiHa41zkFU595aWbckUWc f0Id2M8Iwcam264ERsc0hUSZKkvQmHdriGA2M0dTuDcgAGwCYJq01U4R3Iqb/fFS PpD9uPYOTUiT7mfbKe3Jbzm7HCaeONVHTZfSLpU62Hre4y4OiShpHmmvTOepiUN0 evBdJ4L1g7yAraLiRucm+kFdUXFzv0RDMH0f+YAtJRZNSAdgIEVvJvVo3j0FVwfB BDW+xuvhN9+XxE9hgptgy0ch/h1eLurHWb6rdHBQU6wU8IddVOmuegV2FI6aaVxi pMC1dkaY/ZmfyjhxvokIdNxhNhcv10ilG0AIklGm7vl8jW3vJzv2D5LhiPI4UbOh yb/U9oeiFdq249/Lgsr8Vdt0lv+eUZIYkIgIaer8qMlkAU5VSFcODzEmsCPQbheH xJw70riuwqjXHRDZcx8syRXOQkBh3EWA1bSPBouU57h3/w900JyxlmT0qF0PCPLM 51u1HZovittYIJiipSNz =Rdws -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E3A3DA8-209C-43E1-83D4-928823CCBF04>