Total confusion over toolchain/xdev behavior

[Warner Losh]

On Jul 8, 2014, at 11:36 AM, Dimitry Andric <dim at freebsd.org> wrote:

> On 08 Jul 2014, at 18:23, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> On Jul 8, 2014, at 9:04 AM, Warner Losh <imp at bsdimp.com> wrote:
>> 
>>> 
>>> On Jul 8, 2014, at 12:56 AM, Dimitry Andric <dim at FreeBSD.org> wrote:
>>> 
>>>> On 08 Jul 2014, at 03:56, Warner Losh <imp at bsdimp.com> wrote:
>>>> 
>>>>> 
>>>>> On Jul 7, 2014, at 7:29 PM, Warner Losh <imp at 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.
>> 
>> Also, in the current tree it means different things in different places. In some places it says to build libstdc++, in other places it says to build g++ and friends.
> 
> This was an oddity introduced by theraven@ in r255321, where he introduced MK_GNUCXX, but I have no idea why he conflated the two.  Before this commit, I had a local patch which simply added an option disabling or enabling libstdc++ and libsupc++ (and nothing else).  I should have committed that first... :)

Wish you had :) I’ve taken various stabs at this since your feedback on my initial change w/o being happy with the result. Will keep trying.

> In any case, it would be nice to still have the option to enable building libstdc++, whatever the used compiler is.

Agreed. I’ll make sure that you can specify this. I just get picky about names and meanings :) Is it a requirement to build both libstdc++ and libcxxrt or can it be either/or?

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140708/fe53ac0f/attachment.sig>