Date: Tue, 8 Jul 2014 08:56:12 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, sbruno@FreeBSD.org, Ian Lepore <ian@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Total confusion over toolchain/xdev behavior Message-ID: <67272C53-1908-454A-8E74-14D9A2EA0828@FreeBSD.org> In-Reply-To: <B94CB4F3-FA56-4B17-A4DD-A6F28F521A9C@bsdimp.com> References: <1404688077.1059.115.camel@bruno> <1404766292.65432.43.camel@revolution.hippie.lan> <20B72004-1499-4F99-A7C7-13173C50C7C6@bsdimp.com> <20140707235237.GG97203@ivaldir.etoilebsd.net> <DB29AF3B-C761-4112-A4F6-6CF20159C2E1@bsdimp.com> <B94CB4F3-FA56-4B17-A4DD-A6F28F521A9C@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_98D5528D-DD30-44B5-8F37-9BEC487F512A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 08 Jul 2014, at 03:56, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Jul 7, 2014, at 7:29 PM, Warner Losh <imp@bsdimp.com> wrote: >>=20 >> About the rest=85 Yea, you may be right=85. MK_GNUCXX is an odd = duck, and that=92s >> likely the problem that should be fixed in a different way. It is = really an internal >> variable that should be set based on the actual compiler type = (possibly with an >> override for the odd-duck pair of clang and libstdc++ which may not = be worth >> supporting). It is telling us we=92re doing something horribly wrong = and we should listen >> to that rather than add another compiler-related kludge to the build = system. I=92ll work >> on that bit. >=20 > Perhaps > http://people.freesbd.org/~imp/patch-queue/86gnucxx > might be the best way to cope=85 >=20 > Comments? This would make it impossible to build libstdc++ with clang, and why = remove MK_GNUCXX at all[1]? Maybe the option should be renamed to = MK_LIBSTDCXX or MK_LIBSTDCPLUSPLUS, since that is basically what it = does: enable or disable building libstdc++ and its dependent components. If the compiler is base gcc, you *must* build libstdc++, since it cannot = build libc++. But if you are using e.g. gcc 4.8 as an external = toolchain, you could just as easily disable libstdc++, and build libc++ = instead. I think both should be a user-selectable option. -Dimitry [1]: That is, unless somebody is planning on removing libstdc++ = altogether... but then g++ will also have to go. ;) --Apple-Mail=_98D5528D-DD30-44B5-8F37-9BEC487F512A 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.22 (Darwin) iEYEARECAAYFAlO7lhAACgkQsF6jCi4glqPEXACgw/jzs5IZTiZ6qa4Ikc8ozTEN lkwAoMWS5UJShWpYmoICfewrfBfF4Xkl =qqwi -----END PGP SIGNATURE----- --Apple-Mail=_98D5528D-DD30-44B5-8F37-9BEC487F512A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67272C53-1908-454A-8E74-14D9A2EA0828>