Date: Tue, 8 Jul 2014 09:05:25 -0600 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@FreeBSD.org> 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: <24F7CB1F-80F4-4D5A-9B09-F1D47F029FD9@bsdimp.com> In-Reply-To: <67272C53-1908-454A-8E74-14D9A2EA0828@FreeBSD.org> 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> <67272C53-1908-454A-8E74-14D9A2EA0828@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_D96A7FC0-1DB7-4D00-9B23-05B9DCB3F329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 8, 2014, at 12:56 AM, Dimitry Andric <dim@FreeBSD.org> wrote: > On 08 Jul 2014, at 03:56, Warner Losh <imp@bsdimp.com> wrote: >=20 >>=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? >=20 > This would make it impossible to build libstdc++ with clang, and why = remove MK_GNUCXX at all[1]? Because it is a silly option that=92s mostly an internal knob? We don=92t = need to support options that trip us up at every turn, and MK_GNUCXX has = been doing that since its introduction. > 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. No. Absolutely not. I categorically refuse. This is the *WRONG* way to = do this. If it is to be an option at all, it has to (a) get set correctly when = the compiler changes (it doesn=92t today), (b) not override the user=92s = choice (which is impossible today). > 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. It needs to start working, or it needs to be removed. IT is that simple. = I=92m tired of mopping up options that only half-assed work to support = configurations that aren=92t even close to official on the theory that = they might be someday used which in turn causes real problems for = supported configurations. So, if we can support it without having the user have to care about it = except in the bad-shit-crazy cases, I=92m all for that. Otherwise, it = has to go. What we have now just isn=92t cutting it. Warner --Apple-Mail=_D96A7FC0-1DB7-4D00-9B23-05B9DCB3F329 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTvAi2AAoJEGwc0Sh9sBEAvyoP/36RLDtWg2A3YtTY9NwtNkVr UyXn3TyHAxbkiiaPsHG/W5OD6M5/kldKdvJe1NSp4XZFEvKVGHghhQpqy1I95RWc 6NJtXGN0fw+xiyzRYfDhp5EApzwXD8e+vaH16lRDAMKfwSHLCPfFQv1L/sHPgpNH dYT3Rtc0E+WZ0OGAhdfJEJ10/iACu9cRtjfAJjp6AhqsvxgoNgPUBo7G9Pp3V8EZ 2qRDvtwe1MzUaWCwDy1gPoS71zWInmmtemlsTTqGDXpv1RDoTBadHz1JVED5mdp/ S1vUyA0Zibi19J63y+L4gvthX0Y80xAQNI/UJYR87QL7xGzeNM/F9ACzEOwz07VL NPbZcg5OQV75IYLvxk1+dbwsFOOkngalk0u2gFaG08vmkvepkcB6pk9C6hlxcLme PYW00K5J2m5rD2adNvD7cx5x3Hca5p+rIwlkgU+ZuTr4nn2Stx187GZZNnt0/tzc hvYWYha9V45KPStKhucnRo05Rd4lpWmnPVSwkpZK5NACRLBhMGiqjFC5N6As5tQv 83oW98CuMKrjk97lOLWVi/JGqpKJw909N9chyZkPd+HYqtdEjPkcCxeobMJKzpQh QFo6ogkGmxwGqbKnK+v4+Y2TU/IZtFfemfA84sBkpUL6LzMDSGiKLI5jSsA+YQi5 cyGcjvCXW3GVxTxiXxbr =tZBs -----END PGP SIGNATURE----- --Apple-Mail=_D96A7FC0-1DB7-4D00-9B23-05B9DCB3F329--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24F7CB1F-80F4-4D5A-9B09-F1D47F029FD9>