Date: Tue, 16 Dec 2014 17:32:22 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: David Chisnall <theraven@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: Migration to dynamic libs for llvm and clang Message-ID: <F44F2112-59A7-4351-BEED-AB1B17BDA0C4@FreeBSD.org> In-Reply-To: <74C51AC7-B7ED-4EBC-8506-1554C7CA31FF@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Dec 2014, at 17:15, David Chisnall <theraven@FreeBSD.org> wrote: >=20 > 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). >=20 > That's still potentially an issue if we add local tools that use = libclang APIs (which we may well do). >=20 >> 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. :) >=20 > 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. >=20 > 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... >=20 > 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 --Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlSQXp0ACgkQsF6jCi4glqNh0ACfW9fJ/T0pQ73PF1M0QsTx/EuE kUYAoNgYWGJ0XHBhELq20Ko1w7MLZo1M =a2kz -----END PGP SIGNATURE----- --Apple-Mail=_B09E27DE-31C6-4971-890F-2AA12258F42E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F44F2112-59A7-4351-BEED-AB1B17BDA0C4>