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
[-- Attachment #1 --] 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: > >> >> On Jul 7, 2014, at 7:29 PM, Warner Losh <imp@bsdimp.com> wrote: >>> >>> About the rest… Yea, you may be right…. MK_GNUCXX is an odd duck, and that’s >>> 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’re doing something horribly wrong and we should listen >>> to that rather than add another compiler-related kludge to the build system. I’ll work >>> on that bit. >> >> Perhaps >> http://people.freesbd.org/~imp/patch-queue/86gnucxx >> might be the best way to cope… >> >> Comments? > > 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’s mostly an internal knob? We don’t 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’t today), (b) not override the user’s 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’m tired of mopping up options that only half-assed work to support configurations that aren’t 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’m all for that. Otherwise, it has to go. What we have now just isn’t cutting it. Warner [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24F7CB1F-80F4-4D5A-9B09-F1D47F029FD9>